notes from pairing session 2020/01/16 Chris & CJ
What is a signature in entropic?
- chris wants a binary format
- we have to hash it
- order matters
- let's get fussy
All objects start with type, expressed as a string.
Alice is writing a new library, and she is excited to use the new ES6 syntax. However, she would like to use an older but still good package she found on npm, that exports its interface using CommonJS. She does so easily after reading the NodeJS documentation on how to do this.
Bob is updating a module for his work, and he needs to support existing CommonJS-using codebases as well as a new project that prefers to stick with ES6 for static analysis reasons. He publishes a package that exports both kinds of interfaces.
Carol is updating her popular code coverage reporting tool for the new world. She uses the ESM loader hooks to instrument test code as it is imported so she can get code coverage reporting on par with what she has for CommonJS.
The proposal you’re about to read is not just a proposal. We have a working implementation of almost everything we discussed here. We encourage you to checkout and build our branch: our fork, with the relevant branch selected. Building and using the implementation will give you a better understanding of what using it as a developer is like.
Our implementation ended up differing from the proposal on some minor points. As our last action item before making a PR, we’re writing documentation on what we did. While I loathe pointing to tests in lieu of documentation, they will be helpful until we complete writing docs: the unit tests.
This repo also contains a bundled version of npm that has a new command,
asset. You can read the documentation for and goals of that comma
|2001 silly decomposeActions build firstname.lastname@example.org|
|2002 silly decomposeActions install email@example.com|
|2003 silly decomposeActions postinstall firstname.lastname@example.org|
|2004 silly decomposeActions finalize email@example.com|
|2005 silly decomposeActions refresh-package-json firstname.lastname@example.org|
|2006 silly decomposeActions fetch email@example.com|
|2007 silly decomposeActions extract firstname.lastname@example.org|
|2008 silly decomposeActions preinstall email@example.com|
|2009 silly decomposeActions build firstname.lastname@example.org|
|2010 silly decomposeActions install email@example.com|
|$ touch -t 196508231405.14 ./test.tgz"|
|$ stat ./test.tgz|
|Size: 6012 Blocks: 16 IO Block: 4096 regular file|
|Device: 900h/2304d Inode: 127402426 Links: 1|
|Access: (0644/-rw-r--r--) Uid: ( 1000/ ubuntu) Gid: ( 1000/ ubuntu)|
|Access: 1965-08-23 14:05:14.000000000 +0000|
|Modify: 1965-08-23 14:05:14.000000000 +0000|
|Change: 2016-07-06 17:35:26.871223783 +0000|
uselessd :: information system Edit RecentChanges Preferences Discussion logo
uselessd -- what it says on the tin, plus a complementary kitchen sink and flat tire
So, what is it?
uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project which aims to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design.
An alerting engine for a metrics & monitoring system.
This is the same approach I wanted in my initial spike, only instead of writing a custom collector & using an existing alerting engine (riemann), I'm proposing using an existing collector (hekad) and writing the alerting engine.
I've recently shifted from a straight engineering job to a job with a "dev/ops" title. What I have discovered in operations land depresses me. The shoemaker's children are going unshod. Operations software is terrible.
What's driving me craziest right now is my monitoring system.
What I have right now is Nagios.