re-add papers/research section #1580
Conversation
mschwaig
force-pushed
the
re-add-papers-section
branch
from
d6b9b4b
to
d4fe341
Compare
based on https://web.archive.org/web/20170518051949/http://nixos.org/docs/papers.html and recent works I am aware of with some help from Claude.ai
mschwaig
force-pushed
the
re-add-papers-section
branch
from
d4fe341
to
bd21365
Compare
|
Nice! Closes #830 Off the top of my mind, a seminal paper that deeply concerns Nix is Build systems a la carte. I have a few small nits on the wording, and will add a few comments. Other than that this is really really good, and we can add more papers as we go. |
There was a problem hiding this comment.
One nitpick I have is that the buttons on the publications (Preprint, Download, etc.) have a contrast of 2.53:1 when comparing with the background, which is not that great. It'd be great if you could change this to a color that at least suffices AA contrast. :)
Co-authored-by: Valentin Gagarin <[email protected]>
…ty about license)
works, but layout and arrow animation remains broken
buttons stay at gray-400 for now to make the page look less noisy
now only touch screen layout remains broken
I think they are considered bad style, but they exist so let's make them more readable.
I made the buttons a bit darker now in 7ea4ab6, but I am hesitant to make them any darker than that, because I feel like it makes the page look more noisy. |
| orcidUrl: "https://orcid.org/0000-0002-7384-3370", | ||
| }, | ||
| ], | ||
| year: 2005, | ||
| abstract: | ||
| "The deployment of services — sets of running programs that provide some useful facility on a system or network — is typically implemented through a manual, time-consuming and error-prone process. For instance, system administrators must deploy the necessary software components, edit configuration files, start or stop processes, and so on. This is often done in an ad hoc style with no reproducibility, violating proper configuration management practices. In this paper we show that build management, software deployment and service deployment can be integrated into a single formalism. We do this in the context of the Nix software deployment system, and show that its advantages — co-existence of versions and variants, atomic upgrades and rollbacks, and component closure — extend naturally to service deployment. The approach also elegantly extends to distributed services. In addition, we show that the Nix expression language can simplify the implementation of crosscutting variation points in services.", | ||
| publicationInfo: { | ||
| type: "conference", | ||
| conference: | ||
| "12th International Workshop on Software Configuration Management (SCM-12)", | ||
| location: "Long Beach, California, USA", | ||
| pages: "83–98", | ||
| }, | ||
| preprintOrArchiveUrl: | ||
| "https://nixos.org/~eelco/pubs/servicecm-scm12-final.pdf", | ||
| }, | ||
| { | ||
| title: | ||
| "Efficient Upgrading in a Purely Functional Component Deployment Model", | ||
| authors: [{ name: "Eelco Dolstra" }], | ||
| year: 2005, | ||
| abstract: | ||
| 'Safe and efficient deployment of software components is an important aspect of CBSE. The Nix deployment system enables side-by-side deployment of different versions and variants of components, complete installation, safe upgrades, and safe uninstalls through garbage collection. It accomplishes this through a purely functional deployment model, meaning that the file system content of a component only depends on the inputs used to build it, and never changes afterwards. An apparent downside to this model is that upgrading "fundamental" components used as build inputs by many other components becomes expensive, since all of these must be rebuilt and redeployed. In this paper we show that binary patching between sets of components enables efficient deployment of upgrades in the purely functional model, transparently to users. Sequences of patches can be combined automatically to enable upgrading between arbitrary versions. The approach was empirically validated.', | ||
| preprintOrArchiveUrl: | ||
| "https://nixos.org/~eelco/pubs/eupfcdm-cbse2005-final.pdf", | ||
| doiOrPublisherUrl: "https://doi.org/10.1007/11424529_15", | ||
| publicationInfo: { | ||
| type: "conference", | ||
| conference: | ||
| "Eighth International SIGSOFT Symposium on Component-based Software Engineering (CBSE 2005)", | ||
| location: "St. Louis, Missouri, USA", | ||
| publisher: "Springer-Verlag", | ||
| pages: "219–234", | ||
| }, | ||
| }, | ||
| { | ||
| title: "Nix: A Safe and Policy-Free System for Software Deployment", | ||
| authors: [ | ||
| { name: "Eelco Dolstra" }, | ||
| { name: "Merijn de Jonge" }, | ||
| { | ||
| name: "Eelco Visser", | ||
| orcidUrl: "https://orcid.org/0000-0002-7384-3370", | ||
| }, | ||
| ], | ||
| year: 2004, | ||
| abstract: | ||
| "Existing systems for software deployment are neither safe nor sufficiently flexible. Primary safety issues are the inability to enforce reliable specification of component dependencies, and the lack of support for multiple versions or variants of a component. This renders deployment operations such as upgrading or deleting components dangerous and unpredictable. A deployment system must also be flexible (i.e., policy-free) enough to support both centralised and local package management, and to allow a variety of mechanisms for transferring components. In this paper we present Nix, a deployment system that addresses these issues through a simple technique of using cryptographic hashes to compute unique paths for component instances.", | ||
| publicationInfo: { | ||
| type: "conference", | ||
| conference: | ||
| "18th Large Installation System Administration Conference (LISA '04)", | ||
| location: "Atlanta, Georgia, USA", | ||
| publisher: "USENIX", | ||
| pages: "79–92", | ||
| }, | ||
| preprintOrArchiveUrl: | ||
| "https://nixos.org/~eelco/pubs/nspfssd-lisa2004-final.pdf", | ||
| }, | ||
| { | ||
| title: "Imposing a Memory Management Discipline on Software Deployment", | ||
| authors: [ | ||
| { name: "Eelco Dolstra" }, | ||
| { | ||
| name: "Eelco Visser", | ||
| orcidUrl: "https://orcid.org/0000-0002-7384-3370", | ||
| }, | ||
| { name: "Merijn de Jonge" }, | ||
| ], | ||
| year: 2004, | ||
| abstract: | ||
| "The deployment of software components frequently fails because dependencies on other components are not declared explicitly or are declared imprecisely. This results in an incomplete reproduction of the environment necessary for proper operation, or in interference between incompatible variants. In this paper we show that these deployment hazards are similar to pointer hazards in memory models of programming languages and can be countered by imposing a memory management discipline on software deployment. Based on this analysis we have developed a generic, platform and language independent, discipline for deployment that allows precise dependency verification; exact identification of component variants; computation of complete closures containing all components on which a component depends; maximal sharing of components between such closures; and concurrent installation of revisions and variants of components. We have implemented the approach in the Nix deployment system, and used it for the deployment of a large number of existing Linux packages. We compare its effectiveness to other deployment systems.", | ||
| preprintOrArchiveUrl: | ||
| "https://nixos.org/~eelco/pubs/immdsd-icse2004-final.pdf", | ||
| doiOrPublisherUrl: "10.1109/ICSE.2004.1317480", | ||
| publicationInfo: { | ||
| type: "conference", | ||
| conference: | ||
| "26th International Conference on Software Engineering (ICSE 2004)", | ||
| location: "Edinburgh, Scotland", | ||
| publisher: "IEEE Computer Society", | ||
| pages: "583–592", | ||
| }, | ||
| }, | ||
| { | ||
| title: "Integrating Software Construction and Software Deployment", | ||
| authors: [{ name: "Eelco Dolstra" }], | ||
| year: 2003, | ||
| abstract: | ||
| "Classically, software deployment is a process consisting of building the software, packaging it for distribution, and installing it at the target site. This approach has two problems. First, a package must be annotated with dependency information and other meta-data. This to some extent overlaps with component dependencies used in the build process. Second, the same source system can often be built into an often very large number of variants. The distributor must decide which element(s) of the variant space will be packaged, reducing the flexibility for the receiver of the package. In this paper we show how building and deployment can be integrated into a single formalism. We describe a build manager called Maak that can handle deployment through a sufficiently general module system. Through the sharing of generated files, a source distribution transparently turns into a binary distribution, removing the dichotomy between these two modes of deployment. In addition, the creation and deployment of variants becomes easy through the use of a simple functional language as the build formalism.", | ||
| publicationInfo: { | ||
| type: "conference", | ||
| conference: | ||
| "11th International Workshop on Software Configuration Management (SCM-11)", | ||
| location: "Portland, Oregon, USA", | ||
| pages: "102–117", | ||
| }, | ||
| preprintOrArchiveUrl: "https://nixos.org/~eelco/pubs/iscsd-scm11-final.pdf", | ||
| }, | ||
| ]; |
There was a problem hiding this comment.
Maybe this could be split up into a separate content collection, see https://docs.astro.build/en/guides/content-collections/
There was a problem hiding this comment.
I do not want to spend a lot of time on putting every entry in its own file right now, because that interferes with my own personal workflow for adding and modifying entries and I would also have to add an index to keep them in the intended order.
Astro on the other hand does not seem to like collections where all the content is in one file though (that's what I would like to do at least for now), so that also does not work.
Basically I'd would prefer to keep this as is now, or just move all entries into another file, and then see later on if making it a collection with each entry in its own file makes sense.
src/pages/research.astro
Outdated
| target="_blank" | ||
| > | ||
| <span class="sr-only">Download preprint</span> | ||
| <span class="ml-2 text-sm font-bold text-gray-500 move-button"> | ||
| PREPRINT | ||
| </span> | ||
| <svg | ||
| xmlns="http://www.w3.org/2000/svg" | ||
| class="h-5 w-5" | ||
| viewBox="0 0 20 20" | ||
| fill="currentColor" | ||
| > | ||
| {/* source https://heroicons.com v1.0.6, MIT licensed */} | ||
| <path | ||
| fill-rule="evenodd" | ||
| d="M6 2a2 2 0 00-2 2v12a2 2 0 002 2h8a2 2 0 002-2V7.414A2 2 0 0015.414 6L12 2.586A2 2 0 0010.586 2H6zm5 6a1 1 0 10-2 0v3.586l-1.293-1.293a1 1 0 10-1.414 1.414l3 3a1 1 0 001.414 0l3-3a1 1 0 00-1.414-1.414L11 11.586V8z" | ||
| clip-rule="evenodd" | ||
| /> | ||
| </svg> | ||
| </a> | ||
| )} | ||
| {paper.doiOrPublisherUrl && ( | ||
| <a | ||
| href={ | ||
| paper.doiOrPublisherUrl.startsWith("10.") | ||
| ? `https://doi.org/${paper.doiOrPublisherUrl}` | ||
| : paper.doiOrPublisherUrl | ||
| } | ||
| class="btn-action flex items-center" | ||
| aria-label="View publisher version" | ||
| target="_blank" | ||
| > | ||
| <span class="sr-only">View publisher version</span> | ||
| <span class="ml-2 text-sm font-bold text-gray-500 move-button"> | ||
| DOI | ||
| </span> | ||
| <svg | ||
| xmlns="http://www.w3.org/2000/svg" | ||
| class="h-5 w-5" | ||
| fill="none" | ||
| viewBox="0 0 24 24" | ||
| stroke="currentColor" | ||
| stroke-width="2" | ||
| > | ||
| {/* source https://heroicons.com v1.0.6, MIT licensed */} | ||
| <path | ||
| stroke-linecap="round" | ||
| stroke-linejoin="round" | ||
| d="M10 6H6a2 2 0 00-2 2v10a2 2 0 002 2h10a2 2 0 002-2v-4M14 4h6m0 0v6m0-6L10 14" | ||
| /> | ||
| </svg> | ||
| </a> | ||
| )} | ||
| {paper.abstract && ( | ||
| <label | ||
| for={getToggleAbstractId(paper)} | ||
| class="btn-action abstract-toggle" | ||
| aria-label="Toggle abstract" | ||
| aria-expanded="false" | ||
| > | ||
| <span class="ml-2 text-sm font-bold text-gray-500 move-button"> | ||
| ABSTRACT | ||
| </span> | ||
| <svg | ||
| xmlns="http://www.w3.org/2000/svg" | ||
| fill="none" | ||
| viewBox="0 0 24 24" | ||
| class="h-6 w-6 transform transition-transform duration-200" | ||
| stroke="currentColor" | ||
| stroke-width="2" | ||
| > | ||
| {/* source https://heroicons.com v1.0.6, MIT licensed */} | ||
| <path | ||
| stroke-linecap="round" | ||
| stroke-linejoin="round" | ||
| d="M19 9l-7 7-7-7" | ||
| /> | ||
| </svg> | ||
| </label> | ||
| )} | ||
| </div> | ||
| </div> | ||
| <div class="abstract-content mt-4 text-sm text-gray-700"> | ||
| {paper.abstract && | ||
| paper.abstract | ||
| .split("\n\n") | ||
| .map((paragraph, i) => ( | ||
| <p class={i > 0 ? "mt-4" : ""}>{paragraph}</p> | ||
| ))} | ||
| </div> | ||
| </article> | ||
| ))} | ||
| </div> | ||
| </section> | ||
| )) | ||
| } | ||
| </div> | ||
| </Container> | ||
| </div> | ||
| </Layout> |
There was a problem hiding this comment.
Some parts of these templates look repetitive to me, maybe those could be split up into reusable components. This is currently really hard to read tbh. though it does its job, so good job htere :)
There was a problem hiding this comment.
In principle I agree with this suggestion.
src/pages/research.astro
Outdated
|
|
||
| <style> | ||
| .btn-action { | ||
| @apply p-2 text-gray-400 hover:text-gray-600 rounded-full hover:bg-gray-100 transition; |
There was a problem hiding this comment.
| @apply p-2 text-gray-400 hover:text-gray-600 rounded-full hover:bg-gray-100 transition; | |
| @apply p-2 text-gray-500 hover:text-gray-600 rounded-full hover:bg-gray-100 transition; |
There was a problem hiding this comment.
Thanks. 3c8f22f should fix this. To me it looked what I removed there (my earlier change) did not really have a visible impact.
src/pages/research.astro
Outdated
| <style> | ||
| .btn-action { | ||
| @apply p-2 text-gray-400 hover:text-gray-600 rounded-full hover:bg-gray-100 transition; | ||
| padding: 0.5rem; | ||
| border-radius: 9999px; | ||
| transition: all 0.3s ease; | ||
| display: flex; | ||
| align-items: center; | ||
| gap: 0.5rem; | ||
| } | ||
|
|
||
| /* Default styles - buttons always visible */ | ||
| .btn-action .move-button { | ||
| width: auto; | ||
| opacity: 1; | ||
| margin-left: 0.5rem; | ||
| white-space: nowrap; | ||
| } | ||
|
|
||
| /* Only apply hover animations on devices that support hover */ | ||
| @media (hover: hover) { | ||
| .btn-action .move-button { | ||
| width: 0; | ||
| overflow: hidden; | ||
| opacity: 0; | ||
| transition: all 0.3s ease; | ||
| margin-left: 0; | ||
| } | ||
|
|
||
| .paper-entry:hover .btn-action .move-button { | ||
| width: auto; | ||
| opacity: 1; | ||
| margin-left: 0.5rem; | ||
| } | ||
| } | ||
|
|
||
| .paper-entry { | ||
| padding: 1.5rem; | ||
| background: white; | ||
| border-radius: 0.5rem; | ||
| box-shadow: 0 1px 2px rgba(0, 0, 0, 0.05); | ||
| } | ||
|
|
||
| .paper-entry:hover { | ||
| box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1); | ||
| } | ||
|
|
||
| .content-container { | ||
| display: flex; | ||
| justify-content: space-between; | ||
| align-items: flex-start; | ||
| } | ||
|
|
||
| @media (max-width: 640px) { | ||
| .content-container { | ||
| flex-direction: column; | ||
| } | ||
|
|
||
| .buttons-container { | ||
| margin-left: 0; | ||
| margin-top: 1rem; | ||
| width: 100%; | ||
| justify-content: flex-end; | ||
| } | ||
| } | ||
|
|
||
| /* Abstract Content Hidden by Default */ | ||
| .abstract-content { | ||
| max-height: 0; | ||
| max-width: 600px; | ||
| overflow: hidden; | ||
| transition: | ||
| max-height 0.3s ease-out, | ||
| opacity 0.3s ease-out, | ||
| padding 0.3s ease-out; | ||
| opacity: 0; | ||
| text-align: justify; | ||
| margin: 0 auto; | ||
| } | ||
|
|
||
| /* When Checkbox is Checked, Show Abstract Content */ | ||
| .abstract-toggle-checkbox:checked ~ .abstract-content { | ||
| max-height: 2000px; /* Adjust as needed */ | ||
| padding-top: 30px; | ||
| opacity: 1; | ||
| } | ||
| /* Rotate the SVG Icon When Checked */ | ||
| .abstract-toggle-checkbox:checked + div .abstract-toggle svg { | ||
| transform: rotate(-180deg); | ||
| } | ||
| </style> |
There was a problem hiding this comment.
If you use components, you could apply more tailwind classes, I'd prefer people sticking to tailwind instead of mixing up stuff like this. It's okay to use CSS if it is the last resort, but most of this can be done like the rest of this project does it.
There was a problem hiding this comment.
Noted. I rarely do UI stuff at all, so I was not aware this is bad style. Maybe I should have looked at how other pages are written.
| @@ -31,6 +31,8 @@ sections: | |||
| link: /blog/ | |||
| - name: Newsletter | |||
| link: https://weekly.nixos.org/ | |||
| - name: Research and scientific publications | |||
There was a problem hiding this comment.
This link now looks pretty long in the footer, maybe we should come up with a shorter title
There was a problem hiding this comment.
Maybe. I think 'Research publications' would be good, 'Scientific publications' would be OK as well.
I do like the current title the best, but if it does not look good I am fine with shortening it.
I do think that title of the page itself should stay the same though, and I am not sure we should change it in the footer anyways or not.
|
@thilobillerbeck thanks for the review. Unless you insist, I would like to get this merged as is, without addressing your other suggestions first. I do understand it would be better to write reusable components and use CSS as a last resort and probably using a content collection is a good idea as well, but to be frank I want to limit how much time I am spending on the details of this effort in the short term. |
|
In this case I'd also suggest to merge and fix forward, as from experience if we don't make a decision this will just rot again, which would be a pity for all the love that went into setting it up. |
I get your point, though it'd be great if those points could be adressed in the future, since otherwise this page will at some point be pretty hard to maintain. But I'll merge this for now. Sorry for bothering, I just want to keep this project as maintainable as it is. :D |
I re-added this section, based on https://web.archive.org/web/20170518051949/http://nixos.org/docs/papers.html and recent works I am aware of.
This is just a draft, I still need to check if I got all of the right information.Since the original page was at http://nixos.org/docs/papers.html and this is at http://nixos.org/research, it would also be nice to set up a redirect, or change the URL.
I'm happy to review PRs related to this list.
To make that process easier maybe we should
Feel free to help me work on the text!
I think @fricklerhandwerk wanted to review this.