5 ms·

Same experience here, both on Mac and Windows. They've done a great job making it "just work". The user interface pieces are a bit raw -- perhaps "minimalist" o

by jdub 10y ago

Same experience here, both on Mac and Windows. They've done a great job making it "just work". The user interface pieces are a bit raw -- perhaps "minimalist" or "unobtrusive" would put that in a better light! -- but clearly most of the work has gone into the lower level integration, where it shines. Docker for Mac/Windows, once released, will nuke the ick factor on those platforms from orbit, which can only lead to even more adoption.

m_mueller 10y ago
I hope there's going to be an easy way to package this with your own docker image in order to have a new way to distribute applications. My usecase is running a server locally so you can use a webapp with local network speed and offline access and lots of local storage.
- derefr 10y ago
  Oh sure, there's all sorts of integration possibilities. Docker Applets, ActiveDocker, Docker Web Start... ;)
  - clessg 10y ago
    DockerScript™
- jimmcslim 10y ago
  Isn't that Sandstorm's usecase... more or less?
  - m_mueller 10y ago
    Interesting, this is the first time I'm reading about it [1]. Well, if anything it looks like a web app would have to be rebuilt from the ground up to fit that model. I haven't yet read much about it, but here's a few questions that pop up immediately: 1) If you have a container per data object, doesn't that mean you also have to start a process every time a user opens a document? So forget about doing any computations in the setup. Even just things like using regex patterns in python (that need to be compiled once) or using anything with a VM (that needs to be started) you'd have to give up. Usecase seems to be extremely limited, but maybe I'm not getting something right here. 2) How do you handle indexes, views and collections over a large set of data objects? [1]https://sandstorm.io/how-it-works https://sandstorm.io/how-it-works
    - kentonv 10y ago
      > it looks like a web app would have to be rebuilt from the ground up to fit that model. Not at all! The app market is full of apps that were not originally written for Sandstorm: https://apps.sandstorm.io/ https://apps.sandstorm.io/ Examples: Wekan, Etherpad, Rocket.Chat, EtherCalc, draw.io, Gogs, Dillinger, NodeBB, EtherDraw, ... It turns out that converting a web app to Sandstorm is mostly deleting code. You delete your user management, your collection management, your access control, etc. What you have left is the essence of your app -- the UX for manipulating your core data model, of which you now only need to worry about one instance. > doesn't that mean you also have to start a process every time a user opens a document? Most apps we've encountered only take a couple seconds to start. But we're working on a trick where we snapshot the process after startup and start each grain from the snapshot, thus essentially optimizing away any startup-time slowness. > How do you handle indexes, views and collections over a large set of data objects? Sandstorm is (currently) designed for productivity apps, not for "big data" processing. The data within a single grain is usually small. That said, you can run whatever database you want inside the grain. (I'm the tech lead of Sandstorm.)
      - m_mueller 10y ago
        Thank you for your response. Sorry, I'm still not getting it. Not even talking about big data, what I mean is a very simple database application, say with 10k documents in a document based storage model. Now let's say I want to show a list view and a sum over one of the fields in those documents. You'd probably agree that this is a typical usecase for a productivity app. Now how would I do this in the sandstorm model?
        kentonv 10y ago
        > You'd probably agree that this is a typical usecase for a productivity app. Actually I can't think of any app that matches the abstract problem you describe. Can you give a specific example? Usually the answer to these problems becomes much clearer in the context of a specific app.
        10y ago
- wmf 10y ago
  Running an app in a Docker container in a Linux VM on a magic hypervisor sounds like a lot of work compared to something like Electron or NW.
  - nazgob 10y ago
    Docker does much more then just that. All your dependencies are handled which is not the case with writing multiplatform app in Electron.

by jdub 10y ago

m_mueller 10y ago

I hope there's going to be an easy way to package this with your own docker image in order to have a new way to distribute applications. My usecase is running a server locally so you can use a webapp with local network speed and offline access and lots of local storage.

derefr 10y ago
Oh sure, there's all sorts of integration possibilities. Docker Applets, ActiveDocker, Docker Web Start... ;)
- clessg 10y ago
  DockerScript™
jimmcslim 10y ago
Isn't that Sandstorm's usecase... more or less?
- m_mueller 10y ago
  Interesting, this is the first time I'm reading about it [1]. Well, if anything it looks like a web app would have to be rebuilt from the ground up to fit that model. I haven't yet read much about it, but here's a few questions that pop up immediately: 1) If you have a container per data object, doesn't that mean you also have to start a process every time a user opens a document? So forget about doing any computations in the setup. Even just things like using regex patterns in python (that need to be compiled once) or using anything with a VM (that needs to be started) you'd have to give up. Usecase seems to be extremely limited, but maybe I'm not getting something right here. 2) How do you handle indexes, views and collections over a large set of data objects? [1]https://sandstorm.io/how-it-works https://sandstorm.io/how-it-works
  - kentonv 10y ago
    > it looks like a web app would have to be rebuilt from the ground up to fit that model. Not at all! The app market is full of apps that were not originally written for Sandstorm: https://apps.sandstorm.io/ https://apps.sandstorm.io/ Examples: Wekan, Etherpad, Rocket.Chat, EtherCalc, draw.io, Gogs, Dillinger, NodeBB, EtherDraw, ... It turns out that converting a web app to Sandstorm is mostly deleting code. You delete your user management, your collection management, your access control, etc. What you have left is the essence of your app -- the UX for manipulating your core data model, of which you now only need to worry about one instance. > doesn't that mean you also have to start a process every time a user opens a document? Most apps we've encountered only take a couple seconds to start. But we're working on a trick where we snapshot the process after startup and start each grain from the snapshot, thus essentially optimizing away any startup-time slowness. > How do you handle indexes, views and collections over a large set of data objects? Sandstorm is (currently) designed for productivity apps, not for "big data" processing. The data within a single grain is usually small. That said, you can run whatever database you want inside the grain. (I'm the tech lead of Sandstorm.)
    - m_mueller 10y ago
      Thank you for your response. Sorry, I'm still not getting it. Not even talking about big data, what I mean is a very simple database application, say with 10k documents in a document based storage model. Now let's say I want to show a list view and a sum over one of the fields in those documents. You'd probably agree that this is a typical usecase for a productivity app. Now how would I do this in the sandstorm model?
      - kentonv 10y ago
        > You'd probably agree that this is a typical usecase for a productivity app. Actually I can't think of any app that matches the abstract problem you describe. Can you give a specific example? Usually the answer to these problems becomes much clearer in the context of a specific app.
        10y ago
wmf 10y ago
Running an app in a Docker container in a Linux VM on a magic hypervisor sounds like a lot of work compared to something like Electron or NW.
- nazgob 10y ago
  Docker does much more then just that. All your dependencies are handled which is not the case with writing multiplatform app in Electron.