TIL Cheap SATA Cables can catastrophically reduce transfer speeds.
TIL Cheap SATA Cables can catastrophically reduce transfer speeds.
Hey Portland caribou is coming
Wonder ballroom Mar 3
Replied to a post on snarfed.org:
Was there ever a Google Plus to Atom feed generator made? (PS These services are great!)
$ pip install youtube-dl
Finally, the LaTeX-Font-Settings.tmbundle has been updated to include all seven section scopes, so 1.0 it is.
Some things to come in the future:
Replied to a post on waterpigs.co.uk:
What program is that? Looks useful.
Trying to follow the narrative at the W3C Social Web Working Group has been challenging, and the initial AS2.0 drafts seem significantly different than the existing AS1.0 implementations. Already, there is also an extremely confusing overlap between JSON-LD/LDP/RDF, schema.org vocabulary and other various semantic web technologies. This post will be updated as information comes in.
Goals for these questions: What did AS1.0 do well and not so well, what needs to happen to in order help make AS2.0 a viable evolution that meets the charter goals, and what are the existing overlaps between AS1.0 and other similar standards and what are the proposed overlaps in AS2.0 (i.e. JSON-LD).
Not involved in the WG but develops a popular silo to AS conversion tool called AS-Unnoficial which powers brid.gy.
- 16:38 snarfed> bret: i haven't followed 2.0, but probably not much. i like having AS as a common format, but i generally don't care about the details of the schema
- 16:39 snarfed> bret: …having said that, i am using some of the new 2.0 features, e.g. allowing images in attachments to be lists. https://github.com/snarfed/activitystreams-unofficial/commit/da99bf304322ea382fdd03e67ae01f4a867abf56
- 16:39 bret> snarfed: would you likely track A-U to use AS2.0 given the fairly significant changes?
- 16:40 snarfed> bret: i don't know. maybe?
- 16:40 bret> like check out https://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#h3_example-2
- 16:40 snarfed> no a-u users have asked about 2.0, so i'm not seeing demand yet
- 16:41 snarfed> bret: that fragment doesn't seem to work
- 16:42 bret> what is going on is there are a lot of participants asking for json-ld users, but they are not currently using AS themselves, so just trying to probe different people who are actually consuming/generating it on their throught
- 16:42 bret> s
- 16:42 bret> thoughts*
- 16:43 bret> gah autocorrect kills me
- 16:44 snarfed> bret: ok. i doubt i can help much, but fwiw, most a-u users like it because it normalizes the different silos' data to a common format. they don't care as much what that format is, AS 1.0 or 2.0 or whatever
- 16:45 bret> that was my impression
- 16:53 bret> snarfed: do you have any opinion on calls to change that common AS vocab in fairly significant ways? (in this case to satisfy the LD crowd needs) It seems like this might be disruptive to the primary use case of A-U users, which seems to be consistent/common vocab.
- 16:54 bret> (just in general)
- 16:55 snarfed> bret: i don't have a strong opinion. if 2.0 is that backward incompatible, and if i implemented it, i'd probably support both 1.0 and 2.0 and let users choose
- 16:55 bret> rgr
#indiewebcamp IRC Freenode
Need to research more...
Activity Streams 1.0
[SocialWG will create] Recommendation Track deliverables that standardize a common JSON-based syntax for social data, a client-side API, and a Web protocol for federating social information such as status updates.
- User control of personal data
- Cross-Organization Ad-hoc Federation
- Embedded Experiences
- Enterprise Social Business
Lots of sites claimed to support AS1.0, but AS was criticized over lack of interop. Where did AS diverge in the wild and what would be required to include those divergences.
The SocialWG is working on publishing two drafts of AS2.0 complete with examples serialized as JSON-LD, although it is noted in the spec that JSON-LD serialization is optional. This seems concerning as it increases complexity of the examples of a specification that already is criticized for poor consistency across implementations. Possibly recommend in serializing with the minimal JSON-LD schema vocab (i.e. "@context") rather than full/partial JSON-LD as it is now as a way to address these concerns.
Just collecting these here.
It isn't uncommon to come across unix software that does not conform to the standard unix directory structure:
/bin /include /lib /lib64 /local /sbin /share /tmp
When you are using a system like stow, this non-conformity can be a real pain in the neck since it tends to result in a royal mess in
~/ or wherever you are stowing.
stow allows you to throw a
.stow-local-ignore into (program | dotfiles | config | whatever) folders inside your stow folder. These ignore files use perl regular expressions, one per line, that cause
stow to ignore files and folders than at least one regex selects, with no way to more specifically negate a less specific regular expression (like you can in
The following regular expressions ignores all folders/files that are not apart of the standard unix directory structure:
// is implied each line in the ignore file so just omit those in the actual
# Only stow the following folders ^((?!(\/)bin|include|lib|lib64|local|sbin|share|tmp).)*$
This can be super handy for throwing into a messy binary distribution of a program to avoid stowing
INSTALL files, or even worse, when a program
make install's a bunch of extra unneeded crap into your
stow/program-x.x.x folder. Its also a simple syntax to extend and modify to your needs.
This can also be used in a
~/.stow-global-ignore file, but it might be too aggressive in some situations. Take it case by case.
You can test the ignore file using a dry run in verbose mode:
~ > cd stow stow > stow -S -v -n program-x.x.x # Stow will print a list of files that it will stow without the -n flag
Negating regular expressions is somewhat non-trivial, but we can use a clever trick called "negative look-arounds". It works by using a regular expression that selects everything that does not contain the substring we select in the
(?!string) selector. You can read more about this trick on this excellent stack overflow answer:
Stow includes a number of options for customizing the stow process, but they must be specified at the time of stowing, which makes stow more difficult and finicky to use because a stow process that specifies additional options can't be trivially reproduced at a later time unless careful documentation is kept. Its better to specify how you want the program stowed each and every time so that the stow process is always idempotent:
~ > cd stow stow > stow -S program-x.x.x # program is now stowed stow > stow -D program-x.x.x # program is now unstowed # The stow process should never be different than this
Replied to a post on flutterby.net:
Cool! Fantastic work.
Dandelion, near the sea surface.