7 ms·

I hate to be negative, but this feels like an invitation for very poor bug quality reports where now you have to debug an application AND an OS (the container).

by feld 10y ago

deleted 10y ago
[deleted]
Me1000 10y ago
Hi there, I'm on the RunKit team. I think we've all been in a situation where we have a bug reproducing in front of us but when we ask for help by describe or even give code to someone else they say "hmm, it works on my machine". Since software rarely runs in a vacuum, having better system level access can sometimes be the only way to debug it. Our hope here is that RunKit notebooks make it easier to see what's wrong, even when the problem is less obvious.
- monochromatic 10y ago
  Probably makes more sense to use the container as a backup for cases like that. If the bug does reproduce on other machines, then a code snippet is going to be easier to diagnose than messing around with a whole container.
  - tolmasky 10y ago
    I think there may be a bit of a misunderstanding here. RunKit does not send you a container for you to interact with manually, in fact there is nothing in the RunKit UI to "mess around" with the container itself. RunKit is a coding notebook that is backed by containers (and automatic shrink-wrapping of dependencies) to guarantee determinism over multiple runs. In other words, it is a code snippet, but with a run button attached. Nothing prevents you from 1) copy pasting the code to your own computer to run it exactly the same way as you would have previously done, or even better 2) hitting the "download" link on the left which downloads the code + shrink-wrap file so you are using the same dependencies as the user. On top of that, we have also made stack traces and other elements of the UI a lot friendlier. From a reproducibility perspective, the notebook represents an undeniable instance that the bug did happen, along with all the background information you are usually asked (what version of node? what version of package? any other dependencies?). The goal is to make that all apparent in the code itself, vs extraneous other files like package.json or such. Here is an example: https://runkit.com/tolmasky/my-bug/1.0.0 https://runkit.com/tolmasky/my-bug/1.0.0 If you are interested in the underlying technology, we've documented it here: http://blog.runkit.com/2015/09/10/time-traveling-in-node.js-notebooks.html http://blog.runkit.com/2015/09/10/time-traveling-in-node.js-...
- feld 10y ago
  Thanks for the info!
- philipov 10y ago
  The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. But it seems like when you containerize the environment, you will change the memory layout and risk the same situation where the bug disappears because you've moved it to a different machine.
  - robzyb 10y ago
    > The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. That has not been my experience. Especially with software written under time constraints including the constraint of "this is FOSS software that I'm writing in my free time."
  - spc476 10y ago
    The hardest bug I had to track down exhibited different behavior on different systems. On one system, it only took an hour or two for the program (a daemon) to crash; on another system, several days could pass before a crash. I was able to track it down once I realized that signal handlers were, technically speaking, another thread of execution in a special context ...
  - coldtea 10y ago
    >The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. Not even close. Different classpaths, different versions of packages, some ENV setting like LOCALE causing havoc, a different configuration between the two installations of the programs that are debugged, a single core vs multi core cpu that masks some race conditions, there are literally MILLIONS of things that can, and in my experience, have, cause something to work in one machine and not another. In fact memory access violations do not even register as a blip on the top-100 reasons...
- khedoros1 10y ago
  If part of the idea is to find differences between the working and non-working environments, does RunKit include a way to diff two containers, or something?
  - thinkmassive 10y ago
    It appears to be a notebook backed by containers, so you could presumably use: docker container diff
    - khedoros1 10y ago
      But doesn't that just give you the diff between the image that the container was built from and the current state? If part of the premise is that environmental differences might be the cause of the bug, wouldn't you want to compare two potentially-dissimilar containers?
gravyboat 10y ago
I agree with this. For an open source project it's just going to be ridiculous. "Hey you know all that free work you already do? Well now you can troubleshoot some user's OS issues as well! Doesn't that sound like fun, we all know you love unpaid work!"
- tolmasky 10y ago
  I've responded to this lower: https://news.ycombinator.com/item?id=13545862 https://news.ycombinator.com/item?id=13545862 , but this is not how this feature works. The confusion is completely understandable if you've never used RunKit, but the idea is not to give people containers, but rather a "common ground" where users can provide reproducible test cases.
  - gravyboat 10y ago
    Gotcha,thanks for the additional explanation.

I hate to be negative, but this feels like an invitation for very poor bug quality reports where now you have to debug an application AND an OS (the container).

by feld 10y ago

I hate to be negative, but this feels like an invitation for very poor bug quality reports where now you have to debug an application AND an OS (the container).

deleted 10y ago

[deleted]

Me1000 10y ago

Hi there, I'm on the RunKit team. I think we've all been in a situation where we have a bug reproducing in front of us but when we ask for help by describe or even give code to someone else they say "hmm, it works on my machine". Since software rarely runs in a vacuum, having better system level access can sometimes be the only way to debug it. Our hope here is that RunKit notebooks make it easier to see what's wrong, even when the problem is less obvious.

monochromatic 10y ago
Probably makes more sense to use the container as a backup for cases like that. If the bug does reproduce on other machines, then a code snippet is going to be easier to diagnose than messing around with a whole container.
- tolmasky 10y ago
  I think there may be a bit of a misunderstanding here. RunKit does not send you a container for you to interact with manually, in fact there is nothing in the RunKit UI to "mess around" with the container itself. RunKit is a coding notebook that is backed by containers (and automatic shrink-wrapping of dependencies) to guarantee determinism over multiple runs. In other words, it is a code snippet, but with a run button attached. Nothing prevents you from 1) copy pasting the code to your own computer to run it exactly the same way as you would have previously done, or even better 2) hitting the "download" link on the left which downloads the code + shrink-wrap file so you are using the same dependencies as the user. On top of that, we have also made stack traces and other elements of the UI a lot friendlier. From a reproducibility perspective, the notebook represents an undeniable instance that the bug did happen, along with all the background information you are usually asked (what version of node? what version of package? any other dependencies?). The goal is to make that all apparent in the code itself, vs extraneous other files like package.json or such. Here is an example: https://runkit.com/tolmasky/my-bug/1.0.0 https://runkit.com/tolmasky/my-bug/1.0.0 If you are interested in the underlying technology, we've documented it here: http://blog.runkit.com/2015/09/10/time-traveling-in-node.js-notebooks.html http://blog.runkit.com/2015/09/10/time-traveling-in-node.js-...
feld 10y ago
Thanks for the info!
philipov 10y ago
The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. But it seems like when you containerize the environment, you will change the memory layout and risk the same situation where the bug disappears because you've moved it to a different machine.
- robzyb 10y ago
  > The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. That has not been my experience. Especially with software written under time constraints including the constraint of "this is FOSS software that I'm writing in my free time."
- spc476 10y ago
  The hardest bug I had to track down exhibited different behavior on different systems. On one system, it only took an hour or two for the program (a daemon) to crash; on another system, several days could pass before a crash. I was able to track it down once I realized that signal handlers were, technically speaking, another thread of execution in a special context ...
- coldtea 10y ago
  >The most common situations for having a bug that works on my machine but not other people's have to do with memory access violations. Not even close. Different classpaths, different versions of packages, some ENV setting like LOCALE causing havoc, a different configuration between the two installations of the programs that are debugged, a single core vs multi core cpu that masks some race conditions, there are literally MILLIONS of things that can, and in my experience, have, cause something to work in one machine and not another. In fact memory access violations do not even register as a blip on the top-100 reasons...
khedoros1 10y ago
If part of the idea is to find differences between the working and non-working environments, does RunKit include a way to diff two containers, or something?
- thinkmassive 10y ago
  It appears to be a notebook backed by containers, so you could presumably use: docker container diff
  - khedoros1 10y ago
    But doesn't that just give you the diff between the image that the container was built from and the current state? If part of the premise is that environmental differences might be the cause of the bug, wouldn't you want to compare two potentially-dissimilar containers?

gravyboat 10y ago

I agree with this. For an open source project it's just going to be ridiculous. "Hey you know all that free work you already do? Well now you can troubleshoot some user's OS issues as well! Doesn't that sound like fun, we all know you love unpaid work!"

tolmasky 10y ago
I've responded to this lower: https://news.ycombinator.com/item?id=13545862 https://news.ycombinator.com/item?id=13545862 , but this is not how this feature works. The confusion is completely understandable if you've never used RunKit, but the idea is not to give people containers, but rather a "common ground" where users can provide reproducible test cases.
- gravyboat 10y ago
  Gotcha,thanks for the additional explanation.