diff --git a/notebook/literature.courtesCodeStagingGNU2017.org b/notebook/literature.courtesCodeStagingGNU2017.org new file mode 100644 index 0000000..28a9741 --- /dev/null +++ b/notebook/literature.courtesCodeStagingGNU2017.org @@ -0,0 +1,31 @@ +:PROPERTIES: +:ID: 11ad06b1-c3ad-4675-9fc0-f651bd62a6d7 +:ROAM_REFS: [cite:@courtesCodeStagingGNU2017] +:END: +#+title: Code Staging in GNU Guix +#+date: 2022-06-11 17:36:08 +08:00 +#+date_modified: 2022-06-11 18:10:24 +08:00> +#+published: 2017-10-23 +#+author: Courtès, L. +#+source: https://hal.inria.fr/hal-01580582 +#+language: en + + +- describes the code staging process for package definitions in [[id:be917383-84c4-4bf5-9ca0-b04bfb778f4f][Guix package manager]]; + mainly describing [[roam:Guix G-expressions]] +- creating package definitions often certain parts of the definitions to carry through the build stage; + oftentimes, these parts of code include additional build instructions for non-trivial packages and additional inputs for that package +- while S-expressions (sexp) are nice, they can be verbose at times; + this is where G-expressions (gexp) comes in handy + - gexp are hygenic — they preserve lexical scope across different stages + - they can easily refer to the high-level objects (e.g., packages, local file) in the store (i.e., ~/gnu/store~) + - first-class Scheme values + - binds deployment to staging — when brought into staging, all inputs are also deployed as well +- use cases for gexps + - code sharing between multiple stages; + this is mostly present such as defining packages and building them + - cross-compilation — there are additional operators to denote "nativeness" where it will refer to the "native" version rather than the target version + - package definitions — less verbose definitions which is always nice especially with the use of referring to the absolute file names from the store + - system services — the process and lifecycle of system services is similar to defining packages being composed of multiple stages: one in definition and one in building the services in the init system + - system tests — they can be defined through the =operating-system= interface which are derivations describing entire operating systems; + in Guix, this is implemented through a tool called =marionette= which introduces another stage in the pipeline diff --git a/notebook/literature.greenbergUnixShellProgramming2021.org b/notebook/literature.greenbergUnixShellProgramming2021.org new file mode 100644 index 0000000..9696cf9 --- /dev/null +++ b/notebook/literature.greenbergUnixShellProgramming2021.org @@ -0,0 +1,37 @@ +:PROPERTIES: +:ID: acab6667-11f5-4c85-93ee-627c1db6d574 +:ROAM_REFS: [cite:@greenbergUnixShellProgramming2021] +:END: +#+title: Unix shell programming: the next 50 years +#+date: 2021-08-03 22:42:04 +08:00 +#+date_modified: 2022-06-11 18:23:17 +08:00 +#+published: 2021-06 +#+author: Greenberg, M., Kallas, K., & Vasilakis, N. +#+source: https://dl.acm.org/doi/10.1145/3458336.3465294 +#+language: en + + +- Unix shell is a long-standing tool with its cruft and history built over the past decades; +- the goodies + - ease of composition gluing tools together easily + - mostly found on Unix systems + - capabilities for data streaming + - interactivity and automation +- the blockers + - too dynamic with its environment that + - ease of composition of tools made of different programming languages with different properties made it difficult for research + - there's no single shell environment; + the current ecosystem is made of multiple implementation of the POSIX shell which is made of ~300pp describing the language, arbitrary behaviors, and extraneous tools to go along with it +- the solvable blockers + - no easy way to handle errors; + it can mean the life or death of a system with a misspelling + - not-so-good framework for asynchronous jobs; + performance is acceptable for single-threaded systems but not for multi-threaded ones; + that said, it does exist once you've made yourself familiar with it + - redudant computation; + several tools like [[roam:GNU Make]] does address it but not fully + - not exactly fitting with the modern deployment systems +- some projects to look forward to + - Jash + - Smoosh + - Posh and Pash