The importance of free software to science
Free software plays a critical role in science, both in research and in disseminating it. Aspects of software freedom are directly relevant to simulation, analysis, document preparation and preservation, security, reproducibility, and usability. Free software brings practical and specific advantages, beyond just its ideological roots, to science, while proprietary software comes with equally specific risks. As a practicing scientist, I would like to help others—scientists or not—see the benefits from free software in science.
Although there is an implicit philosophical stance here—that reproducibility and openness in science are desirable, for instance—it is simply a fact that a working scientist will use the best tools for the job, even if those might not strictly conform to the laudable goals of the free-software movement. It turns out that free software, by virtue of its freedom, is often the best tool for the job.
Reproducing results
Scientific progress depends, at its core, on reproducibility. Traditionally, this referred to the results of experiments: it should be possible to attempt their replication by following the procedures described in papers. In the case of a failure to replicate the results, there should be enough information in the paper to make that finding meaningful.
The use of computers in science adds some extra dimensions to this concept. If the conclusions depend on some complex data massaging using a computer program, another researcher should be able to run the same program on the original or new data. Simulations should be reproducible by running the identical simulation code. In both cases this implies access to, and the right to distribute, the relevant source code. A mere description of the algorithms used, or a mention of the name of a commercial software product, is not good enough to satisfy the demands of a meaningful attempt at replication.
The source code alone is sometimes not enough. Since the details of the results of a calculation can depend on the compiler, the entire chain from source to machine code needs to be free to ensure reproducibility. This condition is automatically met for languages like Julia, Python, and R, whose interpreters and compilers are free software. For C, C++, and Fortran, the other currently popular languages for simulation and analysis, this is only sometimes the case. To get the best performance from Fortran simulations, for example, scientists often use commercial compilers provided by chip manufacturers.
Document preparation and preservation
The forward march of science is recorded in papers which are collected on preprint servers (such as arXiv), on the home pages of scientists, and published in journals. It's obviously bad for science if future generations can't read these papers, or if a researcher can no longer open a manuscript after upgrading their word-processing software. Fortunately, the future readability of published papers is enabled by the adoption, by journals and preprint servers, of PDF as the universal standard format for the distribution of published work. This has been the case even with journals that request Microsoft Word files for manuscript submission.
PDF files are based on an open, versioned standard and will be readable into the foreseeable future with all of the formatting details preserved. This is essential in science, where communication is not merely through words but depends on figures, captions, typography, tables, and equations. Outside the world of scientific papers, HTML is by far the dominant markup language used for online communication. It has advantages over PDF in that simple documents take less bandwidth, HTML is more easily machine-readable and human-editable, and by default text flows to fit the reader's viewport. But this last advantage is an example of why HTML is not ideal for scientific communication: its flexibility means that documents can appear differently on different devices.
The final rendering of a web document is the result of interpretation of HTML and CSS by the browser. The display of mathematics typically depends on evolving JavaScript libraries, as well, so the author does not know whether the reader is seeing what was intended. The "P" in PDF stands for "portable": every reader sees the same thing, on every device, using the same fonts, which should be embedded into the file. The archival demands of the scientific record, combined with the typographic complexity often inherent to research papers, requires a permanent and portable electronic format that sets their appearance in stone.
To aid collaboration and to ensure that their work is widely readable now and in the future, scientists should distribute their articles in the form of PDF files, ideally alongside text-based source files. In mathematics and computer science, and to some extent in physics, LaTeX is the norm, so researchers in these fields will have the editable versions of their papers available as a matter of course. Biology and medicine have not embraced the culture of LaTeX; their journals encourage Word files (but often accept RTF output). Biologists working in Word should create copies of their drafts in one of Word's text-based formats, such as .docx or .odt; though these files may not be openable by future versions of Word, their contents will remain readable. Preservation of text-based, editable source files is essential for scientists, who often revise and repurpose their work, sometimes years after its initial creation.
Licensing problems
Commercial software practically always comes with some form of restrictive license. In contrast with free-software licenses, commercial ones typically interfere with the use of programs, which often throws a wrench into the daily work of scientists. The consequences can be severe; software that comes with a per-seat or similar type of license should be avoided unless there is no alternative.
One sad but common situation is that of a graduate student who becomes accustomed to a piece of expensive commercial analytical software (such as a symbolic-mathematics program), enjoying it either through a generous student discount or because it's paid for by the department. Then the freshly-minted PhD discovers the real price of the software, and can't afford it on their postdoc salary. They have to learn new ways of doing things, and have probably lost access to their past work, which is locked up in proprietary binary files.
A few months ago, an Elsevier engineering journal retracted two papers because their authors had used a commercial fluid-dynamics program without purchasing a license for it. The company behind the program regularly scans publications looking for mentions of its product in order to extract license fees from authors. In these cases, the papers had already been cited, so their retraction is disruptive to scholarship. Cases such as these are particularly clear examples of the potential damage to science (and to the careers of scientists) that can be caused by using commercial software.
In addition, certain commercial software products with per-seat licensing "call home" so that the companies that sell them can keep track of how many copies of their programs are in use. The security implications of this should be obvious to anyone, yet government organizations, while adhering minutely to security rituals with questionable efficacy, permit their installation. While working at a US Department of Defense (DoD) lab, I was an occasional witness to the semi-comical sight of someone running around knocking on office doors, trying to find out who was using (or had left running) a copy of the program that they desperately needed to use to meet some deadline—but were locked out of.
Software rot
Ideally scientists would only use free software, and would certainly avoid "black box" commercial software for the various reasons mentioned in this article. But there is another category that's less often spoken of: commercial software that provides access to its source code.
When I joined a new project at my DoD job, the engineer that I was supposed to work with was at a loss because a key software product had stopped working after he upgraded the operating system (OS) on his workstation. The operating system couldn't be downgraded and the company was no longer supporting the product. I got a thick binder from him with the manual and noticed a few floppy disks included. These contained the source code. Right at the top of the main program was a line that checked the version of the OS and exited if it was not within the range that the program was tested on. I figured we had nothing to lose, so edited this line to accept the current OS version. The program ran fine and we were back in business.
The point of this anecdote is to illustrate the practical value of access to source code. Such proprietary but source-available software occupies an intermediate position between free software and the black boxes that should be strictly avoided. Source-available software, although more transparent, practical, and useful than black boxes, still fails to satisfy the reproducibility criterion, however, because the scientist who uses it can't publish or distribute the source; therefore other scientists can't repeat the calculations.
Software recommendations
The following specific recommendations are for free software that's potentially of use to any scientist or engineer.
Scientists should, when practical, test their code using free compilers, and use these in preference to proprietary options when performance is acceptable. For the C family, GCC is the venerable standard, and produces performant code. A more recent but now equally capable option is Clang.
For Fortran, GFortran (which is a
front-end for GCC) is a high-quality compiler and the standard free-software choice. Several more recently developed alternatives
are built, as is Clang, on LLVM. To avoid
potential confusion, two of these are called "Flang". Those interested in
investigating an LLVM option should follow the project called (usually) "LLVM Flang", which is written from
scratch in C++, and was renamed to "Flang" once it became part of the LLVM
project in 2020. Its GitHub page
warns that it is "not ready yet for production usage
", but this is probably
the LLVM Fortran compiler of the future. Another option to keep an eye on
is the LFortran compiler. Although
still in alpha, this project (also built on LLVM) is unique in providing a
read-eval-print loop (REPL) for Fortran.
For those scientists not tied to an existing project in a legacy language, Julia is likely the best choice for simulation and analysis. It's an interactive, LLVM-based, high-level expressive language that provides the speed of Fortran. Its interfaces to R, gnuplot and Python mean that those who've put time into crafting data-analysis routines in those languages can continue to use their work.
Although LaTeX is beloved for the quality of its typesetting, especially for mathematics, it is less universally admired for the inscrutability of its error messages, the difficulty of customizing its behavior using its arcane macro language, and its ability to occasionally make simple things diabolically difficult. Recently a competitor to LaTeX has arisen that approaches that venerable program in the quality of its typography (it uses some of the same critical algorithms) while being far easier to hack on: Typst. Like LaTeX, Typst is free software that uses text files for its source format, though Typst does also have a non-free-software web application. Typst is still in alpha, and so far only one journal accepts manuscripts using its markup language, but its early adopters are enthusiastic.
A superb solution for the preparation of documents of all types is Pandoc, a Haskell program that converts among a huge variety of file formats and markup languages. Pandoc allows the author to write everything in its version of Markdown and convert into LaTeX, PDF, HTML, various Word formats, and more. Raw LaTeX, HTML, and others can be added into the Markdown source, so the fact that Markdown has no markup for mathematics (for example) is not an obstacle. The ability to have one source and automatically create a PDF and a web page, or to produce a Word file for a publication that insists on it without having to touch a "what you see is what you get" (WYSIWYG) abomination, greatly simplifies the life of the writer/scientist. Pandoc can even output Typst files, so those who use it are ready for that revolution if it comes.
Conclusion
The goals of the free-software movement include ensuring the ability of all users of software to form a community enriched and liberated by the right to study, modify, and redistribute code. The specific needs of the scientific community bring the benefits of free software into clear focus and they are critical to the health and continued progress of science.
The free-software movement has an echo in the "open-access movement", which is centered around scientific publication and began in the early 1990s. It has its origins in the desire of scientists to break free of the stranglehold of the commercial scientific publishers. Traditionally, those publishers have interfered with the free exchange of ideas, while extracting reviewer labor without compensation and attaching exorbitant fees to the access of scientific knowledge. Working scientists are aware of the movement, and most support its aims of providing free access to papers while preserving the curation and quality control inherited from traditional publishing. It is important to also continue to nourish awareness of the crucial role that free software plays throughout the scientific world.
Index entries for this article | |
---|---|
GuestArticles | Phillips, Lee |
Posted Jun 4, 2025 14:26 UTC (Wed)
by willy (subscriber, #9762)
[Link] (3 responses)
I found some code which had been written against Python 2.6 and would have needed substantial changes to make it work with 2.7. Part of that was using a library which was no longer available. And I'm no Python expert, so I just gave up.
You're right that open source software gives us an advantage, but we have to have a better legacy story than this! Whether that's preserving digital artifacts better or having a better backward compatibility story or something else ...
Posted Jun 4, 2025 16:07 UTC (Wed)
by fraetor (subscriber, #161147)
[Link] (1 responses)
Software is an area where university based researchers often struggle more than their industry counterparts, largely due to the short term nature of university funding and contracts, and a focus on publication output for promotion, etc. Over the past few years a number of UK universities have established a central pool of RSEs, often employed on a permanent basis, to mitigate this.
However, while there is a lot of focus around reproducibility, especially in the context of FAIR [2], it does seem that a lot of the effort is going towards freezing all the dependencies and effectively reproducing the original environment, whether through conda environments, containers, or VMs. I guess it is the difference between single paper analytics, and creating a reusable analytics tool.
Software is more essential to science than ever before, so this is definitely an area to keep on improving.
[1]: J. Cohen, D. S. Katz, M. Barker, N. Chue Hong, R. Haines and C. Jay, "The Four Pillars of Research Software Engineering," in IEEE Software, vol. 38, no. 1, pp. 97-105, Jan.-Feb. 2021, https://doi.org/10.1109/MS.2020.2973362
Posted Jun 4, 2025 22:01 UTC (Wed)
by kleptog (subscriber, #1183)
[Link]
The projects at $DAYJOB I find the most fun are when I'm given a pile of code written by some researcher or analyst to solve a problem to turn it into something usable. The joy on their faces when you spend an afternoon restructuring their code to produce something more readable and reliable and completes in a fraction of the time is priceless.
Posted Jun 4, 2025 17:21 UTC (Wed)
by fenncruz (subscriber, #81417)
[Link]
Posted Jun 4, 2025 16:24 UTC (Wed)
by joib (subscriber, #8541)
[Link] (4 responses)
Posted Jun 6, 2025 18:38 UTC (Fri)
by parametricpoly (subscriber, #143903)
[Link] (3 responses)
Posted Jun 6, 2025 20:05 UTC (Fri)
by joib (subscriber, #8541)
[Link] (1 responses)
Posted Jun 6, 2025 22:05 UTC (Fri)
by sfeam (subscriber, #2841)
[Link]
Posted Jun 7, 2025 17:37 UTC (Sat)
by gmatht (guest, #58961)
[Link]
I also imagine LyX would be more reliable if you use the last release of the previous version. (i.e. 2.3.8 rather than the latest 2.4.3).
Posted Jun 4, 2025 22:08 UTC (Wed)
by randomguy3 (subscriber, #71063)
[Link] (5 responses)
I think the bigger win for using free software (along with open data) is making it harder to hide flawed analysis. When different experiment appear to disagree, it can provide a way of investigating why, and whether something underhanded (or incompetent) has been going on.
Posted Jun 5, 2025 0:20 UTC (Thu)
by pizza (subscriber, #46)
[Link] (3 responses)
Without the former, there is no point in even attempting the latter.
Let's say your new implementation produces different results with the same data. Maybe the problem is with your implementation, maybe the problem is with the algorithm, or maybe the problem is actually in the original, casting the original conclusions into question.
You often (usually?) don't know what differences from the original may turn out to be material, so ideally you'd try to precisely recreate the original results (ie with the same input and exactly-as-described procedure) before changing anything..
Posted Jun 5, 2025 10:40 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (2 responses)
For example, I've had to work with code that started failing when recompiled for an SGI machine, rather than the Windows NT box it had been written for, and the Debian x86 boxes it had been ported to successfully. We instrumented the code base, and determined that the SGI machine was underflowing intermediates in floating point calculations, where the same code compiled for Windows or Debian was not - because intermediates were being kept in extended precision x87 stack slots, where the SGI was using double precision FPU registers.
Without the ability to compare, I'd just have a chunk of C code that the original author claimed worked "just fine" (and was backed by other users, who also found it working "just fine" on Linux and Windows NT), but which failed on my target system. With the ability to compare, I could find the problem, determine that the hidden assumption is that all FPUs are x87-compatible, and then work with the originator on a fix.
Posted Jun 5, 2025 17:51 UTC (Thu)
by gmatht (guest, #58961)
[Link] (1 responses)
Posted Jun 5, 2025 18:38 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
For example, there's still differences in memory consistency models between CPUs, so code that appears to be reproducible on one CPU model may fail on a different system, simply because it relied on hardware implementation details that aren't true of all implementations.
More insidiously, I've encountered algorithms that contain "harmless" race conditions that happen to be not harmless if you swap, or implementations that have problems if there's more than 256 CPU threads available to them (since you can fit the "number of available threads" counter in a byte, right?), or implementations that "know" that you can't have more than 48 virtual address bits (since that's the limit on the CPU they have today), or otherwise embed false assumptions about hardware.
Similarly, I've seen implementations that "know" that PCIe devices must have their BARs allocated below 4 GiB (since the firmware on their machine did that), or that the CPU numbers are contiguous, or that the CPU numbers convert to NUMA node numbers with a simple mask-and-shift, or that odd numbered CPUs are the SMT siblings of the even numbered CPUs.
All of these are details that are often consistent if you're comparing to a bunch of machines your institution bought - but they're details that can change once you change hardware vendors.
Posted Jun 5, 2025 9:42 UTC (Thu)
by magi (subscriber, #4051)
[Link]
I think that in order to check reproducibility you need automatic tests. Chances are that you will end up with results that are not strictly the same (as in binary equality). The question is, are the results significantly different whatever that might mean in this context. I think this is really one of the big differences between scientific software and "normal" software. In addition what is the correct result anyway, given that simulations are used to explore a system that cannot be tackled otherwise. Another issue with testing scientific software is that the tests might require huge resources (think weather model) or closed data (think medical data).
Having good tests will allow people to convince themselves the software is doing what it is supposed to. It will also help port the software to new systems and deal with the software rot.
Posted Jun 5, 2025 9:51 UTC (Thu)
by magi (subscriber, #4051)
[Link]
Using markdown for writing papers is great. This works particularly well when used with gitlab/github for collaboration and CI/CD pipelines to automate spell checking and pdf production. Obviously LaTeX works equally well but the syntax is slightly heavier. I missed in the article mentioning of reproducible documents. I think the idea comes from the R world where the document contains the code that can be run to produce the outputs for the document. Quarto supports many languages including python and R, uses pandoc to produce the output and can be edited using jupyter notebooks.
Posted Jun 5, 2025 10:37 UTC (Thu)
by taladar (subscriber, #68407)
[Link] (3 responses)
I am thinking of things like not using shared PRNGs from multiple threads where the scheduling order might then give each thread different parts of its (otherwise deterministic) output depending on which thread is scheduled first.
But beyond that some auto-configuration of the program might also be a problem, e.g. detecting the RAM size or CPU core count and scaling operations by that by spawning more threads or processing larger batches at a time.
Posted Jun 5, 2025 11:20 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
And then there's things like using 32 bit counters because you can't overflow them in reasonable time; this is true when things are slow enough, but as they get faster, it can become false. For example, an Ethernet packet is a minimum of 672 bit times on the wire; in 1995, a 32 bit packet counter represented over 8 hours of packets at the maximum standardised rate. However, today's maximum standardised rate (from 2024) is 800 Gbit/s, or overflow in a bit over 3.6 seconds.
The best we can reasonably ask for is that it's possible to follow your documentation and reproduce your results - that can include documenting the hardware, OS and other details of the system you produced the result on. That way, it becomes possible for a future reimplementation of your algorithm to do the A/B comparison between your system, and their new system, even if they've had to get help from a museum to build up the required hardware to reproduce your results.
Posted Jun 5, 2025 13:01 UTC (Thu)
by fenncruz (subscriber, #81417)
[Link]
On your last point you actually want fixed sized batches, for reproducabilitly. Then distribute each batch to a thread as the thread becomes free. That way you always do the same ordering of your floating point numbers ( (a+b)+c /= a +(b+c) in floating point maths). Think about summing elements in an array broken into chunks per thread, naively more threads would mean more intermediate values that need to get get summed up. With fixed sized blocks it doesn't matter whether someone runs your code with 1 thread or 100, the number of intermediate values is the same. So you get the same answer when the intermediate values get added up at the end.
On random numbers you would need each thread to have its own stream, plus someway to initialise each block of work to its own seed (not thread, again as the number of threads might vary between users).
Posted Jun 5, 2025 16:46 UTC (Thu)
by fraetor (subscriber, #161147)
[Link]
As supercomputers are expensive you are often thinking in terms of The Computer rather than a computer. Porting to a different machine is usually a significant task, and to maintain maximum performance you are often using lots of non-portable tricks that will need adjusting. Things like memory size, core count, or core binding are often configured relatively statically.
Because of this a supercomputer port is usually accompanied by an evaluation phase where subject matter experts look at the outputs and decide if it is close enough.
Once you have completed a port then Known Good Outputs (KGOs) are very commonly used within that single machine, to ensure any output change, even to the most insignificant of bits, is able to be explained.
Posted Jun 5, 2025 10:52 UTC (Thu)
by grawity (subscriber, #80596)
[Link]
In particular because .odt isn't even a Word format – it's the OpenOffice/LibreOffice format that Word only has secondary support for.
Though compatibility of LibreOffice with Word-produced .docx vs Word-produced .odt might well be the same these days?
Posted Jun 5, 2025 18:33 UTC (Thu)
by DemiMarie (subscriber, #164188)
[Link] (4 responses)
Posted Jun 6, 2025 10:44 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
The reason people talk about GPUs as non-deterministic is all in arbitration logic; arbitration logic is often deliberately non-deterministic between requesters of the same priority, and in GPUs that happens during memory access and in hardware scheduling of GPU work items.
Also note that having internal non-determinism (e.g. because you're reordering FP operations) does not imply that your result is non-deterministic. You can do things with numerical analysis that prove that, for a given allowed set of possible orders of operation, the output is always the same; if you then ensure that the allowed set of possible orders of operation in your analysis is a non-strict superset of the possible orders of operation due to non-determinism in your implementation, you have a proof that you have a deterministic output from a non-deterministic machine.
And numerical analysis can extend beyond purely numerical results; if your prediction is that a statistical measure of the simulation's output falls in a range, I can do numerical analysis to show that the simulation's output's error bars are such that the statistical measure must fall inside that range if it falls inside an analytically determined range for a single run of the simulation.
Finally, note that if your result is not reproducible, what you're doing is arguably not science; reproducibility is necessary because otherwise you can claim results from your simulation and insist that your hypothesis is correct, even though my results are different and falsify your hypothesis, simply by saying that my run of the simulation is wrong.
Posted Jun 6, 2025 13:11 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Not "arguably", it *cannot* be science.
Science is accurately predicting the results of your experiments, not just doing experiments and "seeing what happens" - that's called playing.
That's why whenever you see "a new experiment has proven that ...", you know either they don't know what they're doing, or they do know what they're doing and it's called propaganda/lying.
It's not Science until you do the exact same experiment and get the result you predicted. Nothing wrong with the prediction being vague, as long as it is correct as far as it goes - you can always refine it afterwards. And then do another experiment, of course!
Cheers,
Posted Jun 7, 2025 16:48 UTC (Sat)
by DemiMarie (subscriber, #164188)
[Link] (1 responses)
Posted Jun 9, 2025 9:54 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
However non-determinism is not the same as non-reproducibility. There exist plenty of non-deterministic algorithms that have a deterministically reproducible output; it's just extra analysis steps to confirm that your result is reproducible from a set of non-deterministic intermediate steps.
And note that for science purposes, we don't necessarily even need a deterministic output; if your prediction is "this simulation will never have an output whose mean is below 64.0", you can do an analysis that confirms that the algorithm's error bars on the mean are (say) ±31.5 due to non-determinism. Then, if the simulation gets an output of 127.0, you know that, while you can't reproduce the exact value, you can deterministically answer the question "is the mean of the output greater than or equal to 64.0" with "yes, because the worst case an attempted reproducer will see is a mean of 95.5, and the error bar on that will tell them that the algorithm's output must be above 64.0".
Posted Jun 7, 2025 18:15 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (10 responses)
Yes and no. There is indeed a standard, which was a gift from Adobe, and we should be grateful.
More recently, Adobe has been adding proprietary extensions to the PDF format and these can only be open using Adobe software. A famous example is XFA forms produced by LifeCycle designer.
Ironically, this was deprecated by Adobe itself. Probably because people don't buy computers anymore. They only have a smartphone and for some reason XFA never worked on smartphones. But Adobe LifeCycle designer is still around and still producing unusable PDFs.
Posted Jun 7, 2025 18:24 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (4 responses)
Dynamic XFA is the "real deal" https://kbdeveloper.qoppa.com/livecycle-dynamic-xfa-forms/
Both static and dynamic XFA have been deprecated in PDF 2.0?
(That entire confusion and lack of standardization is the problem)
Posted Jun 9, 2025 5:07 UTC (Mon)
by DemiMarie (subscriber, #164188)
[Link] (3 responses)
Posted Jun 9, 2025 14:05 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (2 responses)
> JavaScript has been disabled, the form requires JavaScript to validate properly.
The "Validate" and "Clear Form" have no effect.
Maybe it would work better with a higher subscription tiers? But even if it does, we're straying away from "open", "portable" and "reproducible"...
I also tried to convert it to PDF/A and the output still shows "Please Wait..."
I admit dynamic XFA is unlikely to be used by a scientist. But 1. you never know 2. there could be other proprietary extensions.
tl;dr: beware proprietary extensions.
Posted Jun 9, 2025 14:10 UTC (Mon)
by DemiMarie (subscriber, #164188)
[Link] (1 responses)
Posted Jun 9, 2025 16:18 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
Posted Jun 7, 2025 18:30 UTC (Sat)
by leephillips (subscriber, #100450)
[Link] (4 responses)
Posted Jun 7, 2025 19:34 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (2 responses)
This should not be implicit. People should not believe that "PDF" automatically means "good". Usually: yes. Always: no. I think the article as it is now gives that wrong impression.
Posted Jun 7, 2025 19:56 UTC (Sat)
by leephillips (subscriber, #100450)
[Link] (1 responses)
Posted Jun 8, 2025 0:09 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Posted Jun 8, 2025 2:24 UTC (Sun)
by spigot (subscriber, #50709)
[Link]
Posted Jun 8, 2025 5:09 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (1 responses)
The main point is, in 2018 and even more in 2025, a static PDF is a very limited way of communicating science. We can do much better.
A Jupyter notebook is a significant game-changer here. Though it is not accepted as a medium of publication by journals, there is a lot of useful supplementary data out there in such formats. And it is of course important that it is not proprietary, unlike Mathematica. But its dynamic nature is also important.
Posted Jun 9, 2025 19:04 UTC (Mon)
by fraetor (subscriber, #161147)
[Link]
Given their expanded capabilities, notebooks are inherently going to be harder to reproduce in their orignal fidelity than a PDF, which is fully described by a self-contained specification, though how one is meant to read a specification distributed as a PDF leads to other questions. Being open makes reproduction possible, but it is still a significant hurdle.
I think static documents such as PDF still has a role to play, even if it is just a medium to determine one's interest in some work before investigating the code.
The web is an interesting publishing medium, forming a sort of middle ground between static PDFs and the fully dynamic notebook. I see more journals embracing it as a distribution mechanism; some even allow for interactive plots powered by JavaScript. So perhaps that will be the future direction.
Posted Jun 9, 2025 14:35 UTC (Mon)
by Klaasjan (subscriber, #4951)
[Link] (10 responses)
Posted Jun 9, 2025 16:01 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (9 responses)
Posted Jun 9, 2025 17:29 UTC (Mon)
by leephillips (subscriber, #100450)
[Link] (8 responses)
Like GitHub in relation to Git, it’s a thin layer of mercenary slime befouling a limpid core of free software.
Posted Jun 9, 2025 20:58 UTC (Mon)
by Klaasjan (subscriber, #4951)
[Link] (1 responses)
Posted Jun 10, 2025 1:33 UTC (Tue)
by rsidd (subscriber, #2582)
[Link]
I don't think it is as bad as Lee says. Both overleaf and GitHub have their places. But not really relevant to this article -- overleaf is widely used by scientists, as is MacOS, but as a proprietary tool for creating open science.
Posted Jun 11, 2025 16:40 UTC (Wed)
by Klaasjan (subscriber, #4951)
[Link] (5 responses)
Posted Jun 11, 2025 19:07 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (4 responses)
I migrated off GitHub to two other solutions:
I also mirror my repos on salsa.debian.org, but that's not freely-available to anyone; you need to apply for an account and (AFAIK) be developing free software. That runs the Gitlab software, which you can use as a service or self-host.
Posted Jun 12, 2025 9:34 UTC (Thu)
by Klaasjan (subscriber, #4951)
[Link] (3 responses)
Posted Jun 12, 2025 12:22 UTC (Thu)
by dskoll (subscriber, #1630)
[Link]
Gitlab.com also hosts a free tier, though it says that it's for "individuals working on personal projects and open source contributions."
Posted Jun 12, 2025 12:55 UTC (Thu)
by jzb (editor, #7867)
[Link] (1 responses)
I like Codeberg. You might also look at sourcehut, too. It is a bit more... baroque? All its features are supposed to work without JS (it works well with Nyxt, for instance), and it is 100% free software.
Posted Jun 12, 2025 14:05 UTC (Thu)
by liw (subscriber, #6379)
[Link]
Engineers need to do better
Engineers need to do better
[2]: Wilkinson, M., Dumontier, M., Aalbersberg, I. et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data 3, 160018 (2016). https://doi.org/10.1038/sdata.2016.18
Engineers need to do better
Engineers need to do better
This means that most software written by scientists is of poor quality and does not use best practices which will let it run on future substrates.
As someone who has made the move between academia and industry I can assure you that people can and do write bad code in any language industry.
LyX
LyX
LyX
LyX
Monkey testing LyX
Reproducibility
Reproducibility
The other critical point IME is that it's not unknown for algorithms to have external dependencies that aren't documented because "everyone" uses the same setup.
Reproducibility
Reproducibility - NixOS
Historically, it's not just been software (which Docker helps with - since you're now running a static userspace, and NixOS can extend across the kernel) - it's been hardware and firmware as well. Nowadays, x87 is dead, but we're not at a stage where all CPUs behave identically for a given source code.
Reproducibility - NixOS doesn't fix hardware assumptions
Reproducibility
paper production
Scheduling influences on simulation outcomes?
You also get into having to think about what might be different in the future; for example, I've seen problems with an algorithm in the late 1990s that assumed x87 FPUs and was reproducible on all x86 CPUs of the era, but not on future x86 family CPUs (using SSE2 instead of x87), or on MIPS CPUs.
Forwards-compatibility is hard
Scheduling influences on simulation outcomes?
Scheduling influences on simulation outcomes?
.odt
Accelerators, parallelism, and determinism
GPUs do provide the same IEEE 754 guarantees on determinism when it comes to floats as CPUs do; they're fully deterministic machines in that regard.
Determinism, reproducibility, and numerical analysis
Determinism, reproducibility, and numerical analysis
Wol
Determinism, reproducibility, and numerical analysis
CUDA's non-determinism is in scheduling and memory access, not computation itself. This is the same guarantees as you get with a CPU; the computation is deterministic, but the point at which you work across CPU cores is non-deterministic.
Determinism, reproducibility, and numerical analysis
PDF is an open standard, except when it's not
PDF is an open standard, except when it's not
> There are very few PDF viewers that support XFA Dynamic Forms, one can count them on the fingers of one hand.
PDF is an open standard, except when it's not
PDF is an open standard, except when it's not
>
> Please enable JavaScript through Preferences under the Edit menu and reopen the form.
PDF is an open standard, except when it's not
PDF is an open standard, except when it's not
PDF is an open standard, except when it's not
PDF is an open standard, except when it's not
PDF is an open standard, except when it's not
PDF is an open standard, except when it's not
At a previous job we had to save legal documents (e.g. contracts), and the requirement was to use PDF/A, which standardizes a subset of PDF features. It's intended for archival purposes.
PDF is an open standard, except when it's not
Here's a good blog post (from 2018) by Nobel-winning economist Paul Romer, on "Jupyter, Mathematica and the future of the research paper". He makes many of the same points about open science and reproducibility, and not being locked down to a proprietary system. But much more.
Agree on the reproducibility aspect, but not on the static medium of PDF
Agree on the reproducibility aspect, but not on the static medium of PDF
With the emphasis in this article on the venerable and excellent (La)TeX, on free software, and on the collaborative nature of modern science, it may also be relevant to point out the usefulness of Overleaf (see, e.g., wikipedia).
Overleaf
Overleaf
Overleaf
Overleaf
And I do agree having local backups is important and that working locally in one’s preferred editor can be more pleasant.
Perhaps the Wikipedia entry is overly positive about the free nature of the software?
Overleaf
Github
Github
Github alternatives
Github alternatives
Github alternatives
While we're listing alternatives:
I work on, and use, Radicle, which is distributed, is fully free and open source software.
There's also Tangled, another take on distributed, but built on ATproto, which underlies Bluesky.
(For personal reasons, I only care about distributed systems for this.)
Github alternatives