I have spent the last month keeping a fresh Linux install on a secondary laptop and trying every data science notebook I could get running on it. Not a click through the landing page. Not a screenshot tour. Actual data, in a notebook, on Linux, with the kind of dependency hell that real notebooks produce. I am here to report that twelve of them booted and three earned a permanent install.
This is the practical ranking, what I would tell a friend who asked “what notebook should I just install on Linux to do data science,” with the reasoning behind the picks.
What a notebook actually has to do
I define a notebook, generously, as a document that mixes code, prose, and output in a way I can run, edit, and share. Jupyter invented the form. Every notebook since has either extended Jupyter, replaced the runtime, or built a parallel stack that does the same job differently.
The first thing that matters on Linux is whether the project ships with a sane install story. A notebook that requires a custom kernel, a specific CUDA version, and a hand-built Python is not going to be the one I open at 10 PM to look at a CSV. The second thing that matters is whether the cells actually run without state leakage between them. The third thing is whether I can put real code in one cell and real prose in the next cell and not have the layout break. Everything else is polish.
That is the rubric. Twelve notebooks passed the install test. Three cleared the daily use test.
The three that earned a permanent install
JupyterLab is the safe pick for a reason. It is what most data science tutorials assume you are running. It works on Python and R, the kernel catalog is the deepest of any notebook, the extension library covers every workflow I have tried, and the project has been around long enough that weird bugs get fixed within a release cycle. If you only install one notebook, install JupyterLab.
RStudio is the right pick if you live in R. The IDE part of RStudio is the best in any language. The notebook part is integrated rather than bolted on, which means RStudio handles the chunks, the inline output, and the project file layout in a way that Jupyter handles separately. RStudio on Linux has been smooth since the electron rewrite. If you do R, you do not need a comparison.
marimo is the newcomer that surprised me. It is a reactive Python notebook, which means cells re run automatically when their inputs change. That sounds like a small thing until you use it for a week and try to go back to a Jupyter cell you have to re run by hand. marimo stores notebooks as plain Python files, which means git diffs work and PR review works. The install is one pip command and there is no Jupyter in the dependency tree. If you write Python and you do not need the Jupyter kernel catalog, marimo is the cleanest notebook I tested.
The four that are worth knowing but I did not keep
Positron is the data science IDE from the Posit team. It is what RStudio will become once the unification is done. The problem on Linux right now is the install still has rough edges and the Python story is young. Watch this one.
Apache Zeppelin is the right pick if you are doing Spark, Scala, or any of the polyglot runtimes it bundles. Outside of those workflows it is heavier than it needs to be and the notebook format is not as portable as Jupyter’s. If you are not on Spark, skip it.
Livebook is the Elixir notebook. I do not write Elixir regularly. When I did, Livebook was the cleanest path to running Elixir interactively. Worth installing for the Elixir workflow.
Quarto is not a notebook in the traditional sense. It is a publishing system that runs notebooks and renders them to documents. If you are writing data driven articles or reports, Quarto plus Jupyter or knitr is the right combination. If you just want a notebook, Quarto alone is the wrong tool.
The five that did not earn a permanent install but you might still want
IPython is the kernel underneath Jupyter. As a standalone terminal interface it is genuinely useful for exploratory Python, but it is not a notebook and the article promised notebooks. Mentioning it for completeness.
nteract is a desktop notebook app that wraps Jupyter. The pitch is “notebooks outside the browser.” The reality on Linux is that the desktop app has been unstable on Wayland for the last three releases. If you run X11, try it. If you run Wayland, skip it for now.
Pluto is the reactive notebook for Julia. Same pattern as marimo. I do not write enough Julia to need it installed, but the design is worth knowing if you come from the Julia world.
Cantor is the KDE math and science notebook. Frontend integration is real if you live in KDE. Outside of Plasma it is just a notebook with a different theme.
Polynote, Pretzel, BeakerX, Euporie, and Spark Notebook each address a niche I do not have a use case for. Polynote is the polyglot notebook JVM shops used before VS Code notebooks took over. Pretzel markets itself as a modern Jupyter replacement and has not shipped a stable release yet. BeakerX is the Beaker kernel collection for Jupyter. Euporie is a terminal notebook for the rare person who wants Jupyter in a TTY. Spark Notebook is Spark specific and overlaps with Zeppelin.
If you have a specific need that any of those address, install it. None of them made my permanent list because none of them cleared the daily use test on a generic data science workflow.
Trade-offs
Notebooks are not the right tool for everything. Code that has to run in production belongs in scripts. Code that has to be reviewed by other engineers belongs in scripts. Code that has to survive a refactor belongs in scripts. Notebooks are for exploration, for sharing analyses, for teaching, and for the messy middle of a data project where the answer is not yet clear.
On Linux specifically, the install story is genuinely worse than on macOS for half of these. Conda solves a lot of it. Pixi solves more of it. uv solves even more of it for Python specific notebooks. Pick the package manager before you pick the notebook. The notebook choice matters less than the package manager choice, because the package manager is what you fight every time the notebook itself is fine.
If you are choosing between JupyterLab and marimo, the question is: do you need the Jupyter kernel catalog or do you want a cleaner Python first design. The Jupyter kernel library is bigger and older. The marimo design is sharper. Pick by your constraints, not by which sounds nicer.
If you are choosing between JupyterLab and RStudio, the question is: do you write Python or R. Pick the one that matches your language and stop reading comparisons.
What I would tell past me
Four things, if I could send them back to the version of me that bounced between five notebooks a week for years.
- Pick one notebook and stay there for a month. The notebook choice is not the bottleneck. The bottleneck is whether you actually open it and write code in it. Switching every two weeks guarantees you will not get fluent in any of them.
- Install uv or pixi before you install the notebook. The package manager is what fails first. The notebook rarely fails. Solving the dependency story up front is the highest impact move.
- Use git on the notebook directory even if the format is ugly. Notebooks are documents. Documents go in version control. Stop emailing yourself .ipynb files.
- Read the keyboard shortcuts once. Five minutes of shortcut learning saves hours of mouse hunting. JupyterLab has a shortcut cheatsheet in the help menu. Read it.