Let me clarify. If you want a jupyter notebook with an arbitrary number of cores gpus etc juliabox might be your go to solution. Probably you are also willing to pay in that scenario.
If you are in academia and simply want students to have an easy way to open a notebook and do some coding in a browser where relevant packages are already preinstalled then what i proposed is a sensible option.
Sure you can install jupyter in a laptop but you cannot do it in an ipad for example. Therefore using a url with an opened port in an ipad is an easy way to use julia remotely.
If you have a beefy enough machine to use as a server that might work. That doesn’t address making it multiuser (all students will be using and updating the same notebooks on a shared file system) and doesn’t deal with authentication. If those limitations are acceptable, then sure, you can just use a plain notebook running on a server somewhere. I’ve certainly done that for demos, usually when I need a dedicated machine with a lot of cores.
What makes JuliaBox a thing is all the infrastructure for dealing with many users, authenticating them via various external identity services, autoscaling when demand spikes (as it inevitably does the night before any homework is due), and providing a predictable and fairly comprehensive Julia environment with all the packages baked into the system image so that they load really quickly.
I don’t think so. If you are in academia and want to stay there, maintaining IT infrastructure for coursework is probably not the best use of your time.
Universities either have IT staff for this, or outsource it. Which is where JuliaBox comes in.
I understand that since the early days of Julia are not so far away, it is quite difficult to switch gears. I recall helping grad students install 0.4 not so long ago (or so it seems). But Julia is a mature language now, and if you want to deploy it for coursework, going about it personally does not scale.
IMO the way to make it a paid thing is to somehow be able to get compute resources for an entire lab. I would like to see that front and center, like a standard page explaining it and the price for a lab. Right now, if I was a PhD student, I wouldn’t know how to suggest this over another HPC node to my adviser because I wouldn’t have a good price suggestion or any guarantees with it (there’s nothing that says JuliaBox can or usually is sold like this). That’s without even mentioning that I’m not sure about the logistics of using grant money for cloud computing resources.
Are there any plans to release the current implementation of JuliaBox, as we done at GitHub - JuliaCloud/JuliaBox: Juliabox continues to run, but this codebase is no longer current. historically? It would be very nice if departments could offer this service to their students on the department’s hardware. Your point about authentification is very important. Has there also been a decision as to when, after the phase out period, the free service wlll be unavailable? In particular, will it be provided through May or cut off before then?
It will be available through May. The issue with opening up JuliaBox is that:
It is nearly impossible to install and making it easily installable is a lot of additional work.
When it was open we got zero community contributions to the code—it was literally only the people whose job it was to work on JuliaBox who contributed.
Given those two facts, it’s hard to see the point in open sourcing it, but maybe…
My experience with JuliaBox is quite limited, but I think of it similar to the RStudio server version. Laboratories and departments can set up their own servers and docker images or whatnot for in-house use. When that isn’t feasible they may use other solutions like Amazon or rely on the vendor for the computing resources. That way JuliaComputing can focus on the software, support, or computer resources depending on what works for them best rather than splitting among the efforts.
Thanks. I had hoped (optimistically) that it had gotten easier to install over time. Good news it will available to students through May, as that gives us time over the summer to work out some replacement.
There is also JupyterHub, which is the native Jupyter solution for multi-user, authentication, scaling etc. I know that it powers all the Berkeley shared teaching infrastructure (see here for a news-like piece on that).
I actually think it would be much more promising for teaching scenarios to make sure julia works well with JuptyerHub than to open source JuliaBox. Some benefits of that: 1) university IT departments are probably way more likely to setup infrastructure for JupyterHub (because of the Python pull) than something special for julia. Convincing them to add another kernel is probably less difficult than convincing them to install an entirely separate stack like JuptyerBox. 2) there seems to be an active, large community of contributors that work on JuptyerHub specifically for a classroom environment, and it would be good to tap into that. 3) the article I linked to makes it sound as if there are quite a few plugins/extensions to JupyterHub that specifically help with things like assignments etc., so in the end the environment might actually provide more features for a teaching setting than JupyterBox.
And heck, it might all just work already, with the existing IJulia kernel. I guess the main thing that JuliaBox has that might not be available via JupyterHub is the system image story. But hopefully this whole compile time problem will just be solved generally for julia in the medium run…
I’d actually be curious why JuliaBox (the service) isn’t using JupyterHub? Just a historical thing, that JuliaBox was there before JupyterHub was ready?
I’ve commented on this once before, but it seems to be an important topic, so please bear with me.
I believe that
(1) uni courses are important for introducing Julia to a wider audience
(2) introductory uni Julia courses depend on JuliaBox (later courses not)
(3) some unis make it difficult to use cloud bases solutions (no funding or not allowed to require students to pay themselves or just loads of bureaucracy)
I would therefore suggest JuliaBox to treat these courses in a special way. (This is not said in self interest, since I can fund the use of JuliaBox for my own course.)
We went with a local JupyterHub solution because of something like this. With courses that involve programming, I usually like to give a practical exam (this is the problem, code the solution). Rules (which have a hard time keeping up with technological changes) however can be interpreted to require that there is no internet access during the exam — IT suggested that tweaking the firewall to allow nothing but access to our JupyterHub server from the exam computers as the easiest solution.
As an alternative to JuliaBox, https://nextjournal.com/ is staying free for open science, so it’s worth giving it a shot!
Much like IJulia, it should support rich output for the important packages like Interact, WebIO, Plots etc!
The thing that is a bit different is, that we’re not actually using Jupyter hub, mainly to have a more article + publishing centered user experience. But you can import IJulia notebooks and Weave like markdown!
A cool feature on top of this is, that Nextjournal offers an easy way to manage docker images for your course or your julia package.
Every article creates a docker image, which you can export after you installed all your packages + called precompile - then you can just use that as your image for any new article!
We’re also contemplating to offer ahead of time compiled images - but of course anyone could just start creating docker images with AOT compiled julia packages.
Nextjournal is still in closed beta, so you need a sign up code (julia1.0), but we plan to open up soon!
I think there are two separate cases: (1) the sort of “try Julia with no infuriating setup time to see if you like it”, which occurs after @davidanthoff and others evangelize, (2) running a full class for free.
It may be better to separate the two when thinking about funding. For the former, I don’t see why persistence of environment is required. In that sense, a mybinder analogy and infrastructure may be better. In fact, maybe even getting solid mybinder support itself. Maybe that is a feasible thing to ask for funding.
For the second one, if you are running an official course at a university then I think people ultimately need to pay for it or set things up themselves.
The issue with the per user license is less the cost and more the structure of the licensing and vendor management at universities. Individual people running a course are rarely in a position to get money for running courses because of bureaucracy…The amount of effort required to do it right would be a collosal hassle. It might be easier to have a product with concurrent users that can be sold to more central groups could help. On the other hand, this isn’t possible to sell in places like Canada due to privacy legislation that effects cloud users…
Maybe a free educational JuliaBox could be funded by an XSEDE compute grant? https://www.xsede.org/ecosystem/science-gateways . There are gateways already that work via JupyterHubs. It would require restructuring JuliaBox to work on a new compute platform though.
While I sympathize with this from having first-hand experience, I don’t think that organizational inefficiency is a good excuse to get free services, especially given that universities and similar can and do get their act together if forced, shelling out a significant amount of money for software when necessary. Providing it for free is of course nice for the instructors, but it is their responsibility to get organized and obtain funding.
Also, JuliaBox is a convenience service: Julia is free, and easy to install, and nowadays most students have access to a computer (usually their own laptop). One just pay extra for making this even easier.
Completely agree. I don’t see university courses as a reason for the service to be free. I’ve taken one course that required specific software and taught another. In both cases students were required to install the software or there were facilities with computers that had the software.
On the other hand, I could see meetups that try to engage new users as a slight hang up. However, if someone is too stubborn to download a small bit of free software until they are completely sold on its merits, then they might not be ready for Julia. Rarely do people learning R or Python have similar issues.
I think you missed what I said about running course
My point was that getting individual instructors to negotiate running a specific course and paying a per user cost doesn’t work. The issue is not the cost, but the way universities spend money. Individual instructors have money for research funds, and accountants in charge of grants would throw a fit if you spent that on running a course.
That was my suggestion. Individual instructors can lobby central IT groups for a concurrent user license that they could use for classes, and then money for it doesn’t come from an individual researchers grants. But, as I said, those groups would nix the idea in Canada (it would break privacy legislation), and perhaps that is the case in Europe as well.
Actually, the added complexity has made JuliaBox less easy to install over time. It is a fairly complex web service. One possibility could be to make a single click installation inside the AWS marketplace.
We are trying to stretch the dollar until May, but demand is spiking like nothing we have seen before. There’s just no way to predict this!
Indeed - the number of instituions offering such services is definitely on the rise (e.g. CERN’s SWAN). I think ultimately, academic institutions are best served by larger JupyterHub (or JupyterHub-like) installations with multi-language support that are integrated with the rest of their IT infrastructure (e.g. their OwnCloud/NextCloud installation, user data in general, etc.).
For demos, advocating for Julia, workshops/conferences etc. however, JuliaBox can come in very handy, but I understand that limited-time free use will continue to be available on request for such situations.
For more widespread/generic situations (e.g. showing of your package with a live demo notebook), Binder (hope they add Julia v1.0 support soon) may be a good fit.