On Sat, Dec 24, 2016 at 12:51:01AM +1100, [email protected] wrote: > https://github.com/docker/docker/issues/28705 > https://lwn.net/Articles/446528/
thanks, i'll have to read those later today. > So the kernel command-line option might be the best option for etch. possibly. worth a try, anyway. > Also the Jessie kernel will have security support for another couple > of years. There's no reason why you couldn't run a Stretch host with > a Jessie kernel to support Etch docker images if that was necessary. > Of course that would make ZFS kernel module support even more exciting > than it already is... I'd rather just run an etch VM. Or if i really needed etch in a container (or multiple containers) for some reason then a jessie VM running docker or similar....that way i'm only running the old stuff for the things that actually need it. > > > But I can imagine a situation where part of the tool-chain for > > > scientific computing had a bug that was only fixed in a new > > > upstream release that required a new compiler. > > > > that's one of the advantageѕ of VMs, you can keep old software > > alive indefinitely....and that works very nicely with the kind of > > stuff I was doing at Nectar with openstack - basic idea was to > > let researchers start up VMs or even entire HPC clusters of VMs > > (e.g a controller-node VM and a bunch of compute-node VMs, plus > > the required private networking, scripting, configuration, etc) as > > needed for their computational tasks. > > That doesn't even solve the problem. it does for reproducing results from most scientific computing software. in fact, a VM is about the only way to guarantee the exact same software environment for old software running on an old OS (you still have to be careful about the underlying hardware - Intel and AMD, for example, have slightly different quirks and bugs....and Intel has or had a habit of crippling code compiled with their compilers if they detect at run time that it's running on a non-Intel CPU) To reproduce results from an old version of, say, Gaussian (a very popular commercial computational chemistry program) all i need to do is build and keep a VM image that runs it. if/when i ever need to, i just fire up the VM. How is that not solving the problem? The requirement is to reproduce the same results from the same data using the same program (bugs and all), not to get the old software running on a newer, updated linux distro or to re-process the old data with a new improved version(*). What the old version runs on is pretty much irrelevant, as long as it runs and produces exactly the same results. the point of the exercise is academic integrity, being able to prove that you didn't make up your results. if you can't generate exactly the same results, then that's a problem - even if the new results are better or more accurate. (*) If updated, bug-fixed results are required then that's a complete separate issue - and material for a new paper or at a separately published correction. BTW, VMs also solve the problem for other desktop apps that only run in an old version of your distro. ditto for windows apps. For example, i've got a Win XP app(**) that won't run in Win 7. It will run partially in WINE (almost everything works except print and export), but runs fine in a Win XP VM. (**) GURPS GURU, a GURPS RPG character generator - merely freeware, not Free Software so source code is not available...i haven't even been able to track down the author's current contact details, he seems to have vanished off the net sometime in the mid-2000s) > Wheezy lost support for Chromium due to compiler issues. Kmail in > Jessie never worked correctly for large mailboxes. So for me a basic > workstation (lots of mail and web browsing) wasn't functional on > either of those releases. I ended up running Jessie and then Unstable > with a Wheezy image under systemd- nspawn for email which meant that I > couldn't click on a link to launch a browser (not without more hackery > than I had time for). Scientific computing has little or nothing to do with chromium, other browsers, or most other desktop stuff. If there's a GUI at all, it's usually just some kind of front-end app to generate control or data files for text-mode programs (often run on multiple nodes of a cluster), and/or to visualise or post-process the results. > It's easy to imagine a similar chain of events breaking a scientific > workflow. i think you don't know what a scientific computing workflow actually is. it's not like desktop app stuff (they have macs or windows or linux PCs for that), or even like systems geekery. it's a different kind of usage entirely. scientific computing jobs tend to be batch jobs, not interactive. and can take anywhere from minutes to hours, days, months, sometimes even years to run to completion even on large clusters (which are shared resources running other jobs for you and for other people at the same too). You submit the job to the scheduling system (slurm, pbs, torque, whatever) and wait to be notified that it has finished (depending on how busy the cluster is, what resources your job requires - CPU cores, GPU cores, RAM, etc - and what priority your job has, it may not even start running for days or weeks). long-running software tends to checkpoint every so often (in order to recover from that point in case of power-failure or crash etc), and some produce partial/prelimiary output as they work. the closest thing to it in the non-scientific world would be render farms rendering scenes for movies etc. it's actually very similar - large clusters of machines running some rendering program, processing data files (containing 3d models, lighting, textures, etc) as directed by a control file....it might take hours (depending on hardware and scene complexity) to render just a single frame, and a typical movie requires at least 24 frames per second. craig -- craig sanders <[email protected]> _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
