IPython maintainer and Jupyter dev (even if I barely touch frontend stuff these days). Happy to see diversity, keep up the good work and happy new year. Feel free to open issues upstream if you find lack of documentation or issue with protocol. You can also try to reach to jupyter media strategy team, maybe they'll be open to have a blog post about this on blog.jupyter.org
I’m not adding a lot to the conversation, but it’s not often you run into someone who contributes to creating a tool so fundamental to your daily life, career, growth as a researcher etc, so let me just take the opportunity to say: thank you and the rest of your team for creating such an amazing interactive tool.
Thanks @carreau. I think the documentation is amazing! Zasper is built on the great work and documentation from Jupyter team. I will reach out to Jupyter media strategy team.
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.
So we discuss this briefly on our FAQ but let me try to expand on it.
Our goal is to make a modern literate programming tool. On a surface level, a tool like that would end up looking very similar to Jupyter, though with better features. We've mentioned some things we'd like to have in this final tool in our README and also in the post above.
Our first thought was to make a tool from scratch. The challenge was, it's very hard to get people to switch and so, we had to go where people already are - that meant Jupyter.
We could've made this one feature an extension with some difficulty (in-fact, our early experiments, we started by making an extension). It would have some downsides - we wouldn't have granular control over certain core Jupyter behaviours like we do right now (for eg, we wanted to allow creating hidden folders to store some files). But we probably could have made a 95% working version of Pretzel work as a jupyter extension.
The bigger reason we chose to fork was because down the line, we want to completely change the code execution model to being DAG based to allow for reproducible notebooks (similar to https://plutojl.org/ for eg). Similarly, we want to completely remove Codemirror and replace it with Monaco (the core editor engine in VSCode) to provide a more IDE like experience in Jupyter. These things simply couldn't have been done as extensions.
Project that contains (contained?) porn in the source tree https://github.com/Alex313031/thorium/pull/469 and I've heard the maintainer also promotes some quite reprehensible stuff. So I can't support it.
Didn't know that. That's weird. Seemed like a cool project from the GitHub :S but I was a little surprised I found such a gem that no one had posted in the last year! haha :)
BTW - how did you know that? Where did you hear about that? And what reprehensible stuff? o_O Now you've got me intrigued! haha :)
edit: I looked into it a little more and I kinda have the feeling that this could possibly be a novel-in-this-domain (yet-ancient-globally) way to takeout a potential (in this case, "browser fork") competitor: just plant something morally reprehensible about them, to lie/dissemble to try to trash their reputation and make people scared to associate.
If this were what it is, it would reveal that the simple act of forking (successfully -- moderately) a browser was so threatening to the browser monopolies as to be surprising. This is interesting! hahaha :)
This is sad. I have been wanting a everything from a Chromium based browser that this appears to have on the box.
I can't install this on my work computer, which is where I need to solve the M$ Teams in Chrome/Chromium making my laptop sound like a 747 while slowing to a snail's pace.
Edit: To be 100% clear, my issue is with unknowingly one day the author could accept some NSFW content into the project, and it unknowingly make its way to my corporate issued laptop through an auto-update. The guy opened the door to this type of risk when the content was put there originally. I'm all for easter eggs, but when it's NSFW content inside a thing that people use for work, nope.
have you tried librewolf recently? I've been using it for 3-4 months just to get off chrome based stuff and I have been pretty impressed. It mostly works better than chrome and at least as well as brave for all the stuff I have thrown at it (I like the tabs better, I really like the container tabs option so I can stuff the spyware.. err social media in a very isolated framework), I really like that all the extensions I was using on chrome/brave work in librewolf or have better options. My only annoyance so far is bitwarden behaves weirdly in private windows and that's very minor.
I use FF as my daily for work. Chrome is simply there for Teams. Teams doesn't work so well in FF. I can't imagine Librewolf is any better than FF as far as Teams though.
I use FF containers for the tab isolation you're describing. It works very well for managing multiple AWS accounts at once.
Depends on what kind of porn. Society needs porn. If it is legit adult porn stuff, that's ok. I would prefer donating to legit porn cause than any political superpacs. You know, some societies view politicians worse off than whores. At least whores earn honest work. You have no idea what kind of unprotective act those politician exposed to (I have decades experience in this industry, it is way more dirty than Hollywood shown)...I can name a few: Feinstein, Biden, Pelosi, AOC, Mitt, etc.
In this repo: furry. A coworker of mine reported another repository of this author (or another contributor?) for according to my coworker containing CP. Read issue 474 as well.
afaik it wasn't CP per se, it was images of botched circumcisions because he is very anticircumcision and had that as evidence for why. Still not appropriate to be anywhere near a git repo but the context is vastly different than cp. This doesn't change the recommendation to not touch this project with a 100 foot pole, but I think context is important.
Hardly reprehensible. Not a very "professional thing sure, I wouldn't trust a browser made by someone who puts porn in the source but its not like its a moral failing for what seems to be someone's side project
Edit: I see the accusations of containing cp, that's way more concerning and obvious why you didn't link it but you could have just said that.
Yeah, man. Honestly it's kind of a sexy picture that yiff png^0. I ain't into furry shit and I think it's weird, but that's a pretty sexy pose right there for people of a certain orientation.
And hilariously it ain't no different to stock-standard fare you see everyday on tabloids, TV, or Instagram! Like WTAF people having a moral-panic-meltdown over this shit? hahaha. Secretly Google just melting because somebody actually made a good Chrome fork. Tho I'm scared by even thinking of saying this I'll have to kiss goodbye to my GMail account, and they'll probably cancel all my accounts but still keep charging my credit card with no way to purge, right? Amiright, ABC.XYZ? Sergey, I thought we were freeeeeeens? :) heh.
I mean, weird to include it in a GitHub repo, but not evil. The fact that some NPCs are falling over themselves to call this evil (while probably repressed-guilt-projectively retreating to their private stashus of furry-et-al pon when the sun rises) suggests there's "rotten" in the state of browser forking, methinks! hahahahaha :)
While I agree this is marketing stunts in general, sometime the difference between 99.5 and 99.6 reemission is 0.5 vs 0.4 percent absorption. so one way of seeing it the second one is 20% better than the first one at not heating the building.
This is often the case for percentages "close" to 100%, e.g: with LED efficiency, for powerful LEDs the problem is not the quantity of light emitted but dissipating the heat that may need active cooling, so what may look like a few percent improvement is luminosity may actually be a much stronger decrease of the size of active cooling,
Or semi-transparent mirrors in physics, where you really make a difference between 99.95 and 99.96% reflectance, because what you really look at the transmitance.
As a curiosity, what would it entail to make the two tgz byte-for-byte identical ?
There was/is some discussion in setuptools about how to normalize the tarball (https://github.com/pypa/setuptools/issues/2133#issuecomment-...) coudl something similar be applied to Building Python itself ?
The suggestion there (uid = gid = 1000; uname = user; gname = users) isn't great.
Just use uid = gid = 0, and omit uname/gname.
If you're distributing software via a tarball, the uid/gid bits are meaningless. They only make sense when you archive / backup a directory and plan to extract on the same system.
If you set them to anything other than 0, it may happen that when the tarball is extracted as root user, ownership is changed to the uid/gid of the tarinfo provided those exist on the system. That's a lot of fun!
Python itself in fact tries to chown files when extracting a tarfile (under sudo).
If you set uid = gid = 0, then at least when extracting as root, the files remain owned by root.
Thanks for advice, and I assume you are the one who commented on the upstream issue. This show it is not trivial, and it would be nice to be done automatically by default.
I believe the only differences were uid/gid and username/groupname values between the two tarballs. One had the information of Thomas Wouters, the release manager of 3.12, and the other had generic GitHub Action usernames/groups.
Normalizing these values to something known like 0/0 would have done the trick.
> As a curiosity, what would it entail to make the two tgz byte-for-byte identical ?
It can't be that complicated. The tarballs autogenerated by GitHub (using `git archive`) were byte-for-byte identical for years, until GitHub upgraded git and things broke because entire ecosystems had started to rely on that.
It's intended to solve exactly this problem, but in reverse -- a tarball is extracted to source, and we want to ensure that the sources we've extraced can be traced back to the original tarball.
Hum, that is interesting. I'm more thinking that in a perfect world the pristine-tar delta file should be empty. (Assuming I understand what pristine-tar is doing correctly).
For example I tend to use SOURCE_DATE_EPOCH to be the timestamp of the commit to make sure that anything that embed time is reproducible without extra instruction/manual process specific file.
Thanks for asking those question, and with the number of comments, thanks if you reach mine.
One of my hope is that this will affect the market and in particular the ability to have non-connected variants of some appliances.
My hope is that if the cost/risk if high enough, manufacturer won't put pointless connectivity - or at least the ability to disable connectivity – to some models.
I'm also hopping that will put an end of application that collect personal data, like my headphone app requiring I turn on GPS and give it access to my location start.
If you like interactive c/c++, how a look at https://github.com/jupyter-xeus/xeus-cling, that allow you to run the c/c++ repl in Jupyter, either in web interface, and terminal interfaces.
I'll second cling, when having to teach C/C++ to beginner programmers I usually start them out with cling to familiarize them with C statements/expression/printing before delving into functions.
(When teaching I view high token count for hello world as a pitfall, starting with a REPL I can dive directly into computation before they start getting stuck on syntax)
reply