It's a great reality check, poking into human nature, morality, suffering, all with real life examples and littlz tolerance for bullshit without delusion of grandeur.
You can't tell your user to "echo 'awesomecopter' | sudo tee /etc/hostname" if you may have windows users.
And even for purely linux user, "Good: Give the reader a bash snippet that evaluates conditional logic for them" is quite a scary wall of code for a beginner that as no idea why copy/paste that.
All in all, don't confuse "giving the shortest path to a working solution" and "teaching", which both can be in a tutorial, but they have different goals and you should choose accordingly.
I think the "Teach one thing" is probably the best advice in the article, and too often ignored. I remember as a kid reading Swinnen's book to learn Python and having to understand OOP with his example using ions was a terrible experience.
And if you think "well you should have known that, they teach it in school", you are missing the point.
That being said, writing an excellent tutorial takes a lot of work. Way more than a good-enough one. Choose wisely.
I really wish more tutorial makers would do the "teach one thing". Like I dabble in gamedev, and most people who create content for it generate 45 minute to many hour long tutorials that are end to end, instead of teaching "this is how you deal with navigation" "this is how you handle movement" etc. Means people who want to learn stuff are stuck interacting with a massive block of stuff which makes extricating out the part they need and planting it in their own project wildly harder.
I won't disagree with that. I will say pip and venv ending up being a massive chain is entirely unsurprising because Python environment management is a mess to begin with. But then there are a lot of gnarly topics that can be hard to find useful information on.
One thing that doesn't help all this is more and more tutorials going on Youtube (I admit I've made a couple, which were topic focused) is that so many people just want an entire soup to nuts answer instead of the tools to piece together their own solution from the parts, which makes gaining traction and getting that information to people a lot harder.
But without a general change in how people look at learning I dunno what fixes that problem.
I think that's fairly normal, having alternative frontends can only be beneficial to the community. I know it also look like there is a single Jupyter team, but the project is quite large, there are a lot of constraints and disagreements internally and there is not way to accomodate all users in the default jupyter install. Alternative are always welcome ; at least if they don't fragment the ecosystem by being not backward compatible with the default.
Also to be fair I'm also one of the Jupyter dev that agree with many points of OP, and would have pulled it into a different direction; but regardldess I will still support people wanting to go in a different direction than mine.
The Jupyter community maintains a public spec of the notebook file format [1], the kernel protocol [2], etc. I have been involved with many alternative Jupyter clients, and having these specs combined with a friendly and welcoming community is incredibly helpful!!!
Vscode and vscode.dev support wasm container runtimes now; so the Python kernel runs in WASM runs in a WASM container runs in vscode FWIU.
Vscode supports polyglot notebooks that run multiple kernels, like "vatlab/sos-notebook"
and "minrk/allthekernels". Defining how to share variables between kernels is the more unsolved part AFAIU. E.g. Arrow has bindings for zero-copy sharing in multiple languages.
Cocalc, Zeppelin, Marimo notebook, Data Bricks, Google Colaboratory (Colab tools), and VSCode have different takes on notebooks with I/O in JSON.
There is no CDATA in HTML5; so HTML within an HTML based notebook format would need to escape encode binary data in cell output, too. But the notebook format is not a packaging format. So, for reproducibility of (polyglot) notebooks there must also be a requirements.txt or an environment.yml to indicate the version+platform of each dependency in Python and other languages.
repo2docker (and repo2podman) build containers by installing packages according to the first requirements .txt or environment.yml it finds according to REES Reproducible Execution Environment Standard. repo2docker includes a recent version of jupyterlab in the container.
JupyterLab does not default to HTTPS with an LetsEncrypt self-signed cert but probably should, because Jupyter is a shell that can run commands as the user that owns the Jupyter kernel process.
MoSH is another way to run a web-based remote terminal. Jupyter terminal is not built on MoSH Mobile Shell.
Cocalc's Time Slider tracks revisions to all files in a project; including latex manuscripts (for ArXiV), which - with Computer Modern fonts and two columns - are the typical output of scholarly collaboration on a ScholarlyArticle.
Docker Desktop and Podman Desktop are GUIs for running containers on Windows, Mac, and Linux.
containers become out of date quickly.
If programmer or non-programmer notebook authors do not keep versions specified in a requirements.txt upgraded, what will notify other users that they are installing old versions of software?
Are there CVEs in any of the software listed in the SBOM for a container?
There should be tests to run after upgrading notebook and notebook server dependencies.
> Any new package format must support cryptographic signatures and ideally WoT identity
Any new package format for jupyter must support multiple languages, because polyglot notebooks may require multiple jupyter kernels.
Existing methods for packaging notebooks as containers and/or as WASM: jupyter-docker-stacks, repo2docker / repo2podman, jupyterlite, container2wasm
You can sign and upload a container image built with repo2docker to any OCI image registry like Docker, Quay, GitHub, GitLab, Gitea; but because Jupyter runs a command execution shell on a TCP port, users should upgrade jupyter to limit the potential for remote exploitation of security vulnerabilities.
> Non programmers using notebooks are usually the least qualified to make them reproducible, so better just ship the whole thing.
Programs should teach idempotency, testing, isolation of sources of variance, and reproducibility.
What should the UI explain to the user?
If you want your code to be more likely to run in the future,
you need to add a "package" or a "package==version" string in a requirements.txt (or pyproject.toml, or an environment.yml) for each `import` statement in the code.
If you do not specify the exact versions with `package==version` or similar, when users try to install the requirements to run your notebook, they could get a newer or a different version of a package for a different operating system.
If you want to prevent MITM of package installs, you need to specify a hash for the package for this platform in the requirements.txt or similar; `package==version#sha256=adc123`.
If you want to further limit software supply chain compromise, you must check the cryptographic signatures on packages to install, and verify that you trust that key to sign that package. (This is challenging even for expert users.)
WASM containers that run jupyter but don't expose it on a TCP port may be less of a risk, but there is a performance penalty to WASM.
If you want users to be able to verify that your code runs and has the same output (is "reproducible"), you should include tests to run after upgrading notebook and notebook server dependencies.
Well, this is not the first level, but this is the level entry weapon.
Plus, left and right arrows rotate the characters since it's keyboard only, but in modern FPS you are used to having them laterally move you and you rotate with the mouse, so your reflexes are off.
In Windows the issue is that alt+space will by default open the window's control menu (for minimize/maximize/move/etc.). Pressing space down and then alt will work though.
Probably because firefox has alt+(left|right)arrow as global navigation bindings, and is capturing them before the captcha can get them. requesting a fullscreen gaming mode avoids more key binding issues, but probably ruins the "captcha" feel.
nice, that was the first thing that I noticed that I kept trying to do. It makes it a lot easier. I forgot about how clunky controls can be for older games without retroarch rebinds and stuff. I was playing Perfect Dark last night on my Steamdeck and I was able to bind the controls to a modern layout (left-stick walk, right-stick look, etc...) and it makes the game a ton easier.
You'll let me know the next time you'll have to require the permission of your dog to pee, or when it can trigger surgery to cut your balls or put you down.
It's a great reality check, poking into human nature, morality, suffering, all with real life examples and littlz tolerance for bullshit without delusion of grandeur.