<ocdtrekkie>
paulproteus: Yeah, it's gotta rise like 12 more feet before I'd have to move my car, and another 10 feet on top of that before it'd risk my second story condo, which would likely be "Noah's Flood" level water.
<ocdtrekkie>
But it's high.
<ocdtrekkie>
Six feet and the main road will not be passable.
gopar has quit [Quit: Leaving]
natea has joined #sandstorm
<kentonv>
ocdtrekkie: We will implement migration (between arbitrary Sandstorm servers) someday, but there are a lot of higher priorities.
<ocdtrekkie>
Yeah, I'm just wondering if my alpha -> oasis concept is as unmanageable as I assume it is.
<kentonv>
it could work someday
<kentonv>
I would not expect oasis to be "more stable" than sandstorm yet. It will get there. It _does_ have more capacity, though.
natea has quit [Quit: natea]
<ocdtrekkie>
And when oasis launches, how long will alpha stick around?
<ocdtrekkie>
I'm just curious if I should be doing :effort: once I get my beta invite or not. :P
natea has joined #sandstorm
<kentonv>
ocdtrekkie: we'll implement migration before we shut down alpha.
<ocdtrekkie>
Spiffy.
sfbae has joined #sandstorm
<sfbae>
so, I'm surprised that sandstorm doesn't have an app for one of the simplest and common uses for a server: file storage/synchronization. why is that?
<paulproteus>
Hi sfbae !
<paulproteus>
Two answers.
<paulproteus>
0. Hi! Glad you are stopping by.
<sfbae>
paulproteus: hi, thanks for the welcome
<paulproteus>
1. The places where Sandstorm shines the best are places where each document is an instance of an app and where it makes sense to share each app instance/document individually. Etherpad is a good example of that.
<paulproteus>
So the Sandstorm core devs that have been packaging things have focused on apps like that.
<paulproteus>
2. We have a preference toward minimalism, and also toward "You click one thing and it works" at Sandstorm, and it's hard to find document syncing apps that work like that.
<paulproteus>
3. The way we allow apps to be accessible by other code is HTTP(S)-only, with no support (yet) for other protocols like FTP or SFTP.
<paulproteus>
Or SMB or NFS or CIFS etc.
<paulproteus>
Having said all those things, I would love to see file syncing apps.
<paulproteus>
I'm in the process of improving the packaging guide.
<sfbae>
paulproteus: hrm, i think even just over HTTPS an upload/download web interface and file serving feature (for my use case, a library of PDFs that any browser can render)
<paulproteus>
Yeah -- XgF wrote an app called GitWeb Pages recently that does that, except it skips the upload/download web interface and lets you use git for the file pushing around.
<paulproteus>
I think this sort of thing would be super useful too, sfbae, yeah.
<sfbae>
heh, well i wanted to use it with a jailed device like an ipad
<paulproteus>
I think in a way, we have been waiting for some clear explanation of how people would want to use such a thing, and preferably find some code that already does that specific thing and is pretty popular (so we can "merely" package that, rather than writing something new).
<sfbae>
well, i can decribe my desired workflow
<kentonv>
I bet someone could write a functional file upload/organize/download app in like half an hour... :)
<kentonv>
hard part is client-side FS sync, really
<paulproteus>
Yeah, I guess the other reason I forgot to provide, in the list above, is "We've also been busy building platform features to make sure Sandstorm is something new and interesting."
<paulproteus>
sfbae: I'd love to hear about your needs!
<paulproteus>
I don't know that the app you need will magically appear.
<paulproteus>
I'd love to know more about you, too -- maybe I can help you package an existing app and make good use of it.
<sfbae>
i have a big and continuously growing directory of PDF that i need to eventually read. syncing that the way I want with a reading device like my ipad is not so easy (I can't symlink out of an icloud folder which is dumb, I use OS X as well) so It would be cool if I could have an easy to setup app on something on sandstorm which I can rsync a directory on my computer with and
<sfbae>
can also access via a web browser to upload/download via an ipad (sometimes I find PDFs on my ipad and want to push it to my PC)
jadewang has quit [Remote host closed the connection]
<sfbae>
the latter part of uploading PDFs via ipad's web browser may not be possible but that's not such a common case i guess
<sfbae>
kentonv: well it's good to know that it's possible in sandstorm
jadewang has joined #sandstorm
<kentonv>
once we have Cap'n Proto APIs, I'd like to wire my FUSE<->capnp adapter up to a trivial Sandstorm app that just stores files...
<kentonv>
just because it would be so easy
<paulproteus>
It's like Plan 9 In The Cloud
<kentonv>
currently, ironically, we don't support Cap'n Proto APIs, only HTTP
<paulproteus>
(I had no point, I just wanted to say)
<kentonv>
mostly because capnp doesn't have a defined crypto transport yet
<paulproteus>
sfbae: That sounds like it would be pretty neat to have, yeah.
<sfbae>
i feel like my specific workflow is easily done with a low maintenance rsync + nginx configuration
<sfbae>
can write a little script to trigger a sync manually etc
<paulproteus>
It's _almost_ something you can do with GitWeb pages, too.
natea has quit [Quit: natea]
<sfbae>
paulproteus: supposedly git doesn't like large files though?
<paulproteus>
Yeah, it doesn't love them (though arguably it doesn't _hate_ them, doubly so if the files don't change themselves).
<paulproteus>
If the total repo size ends up less than a gig, git is probably fine.
<kentonv>
yeah, I think binary files work fine, they just won't be efficiently delta-compressed if they change. But yours won't change.
<kentonv>
rsync would not be easy for us to support since it's not an HTTP-based protocol
<kentonv>
webdav is something we do intent to support... someday
<paulproteus>
3GB _might_ work fine, too.
<paulproteus>
I kind of want to test this now.
<sfbae>
largest PDF appears to be 48MB lol
<paulproteus>
That should be pretty livable.
<kentonv>
I think there are lots of git repos that are multi-gigabyte
<sfbae>
ya and probably many more files
<kentonv>
they're a pain to initially download, of course
<paulproteus>
Not _oodles_ more of a pain than the 3GBs of files themselves, though.
<sfbae>
also, other questions: when do you think a stable version will be released?
<sfbae>
(not to say whatever is out is not stable, but I haven't looked into it yet)
dwrensha has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.5/20150525141253]]
<ocdtrekkie>
sfbae: I've been using the Alpha server for... a while.
<ocdtrekkie>
It's never been horrifically broken (for long) and I've never lost data.
<ocdtrekkie>
Kenton's alpha software is arguably probably as stable as most people's 'stable' software.
<ocdtrekkie>
Hey, couldn't you use Hacker CMS?
<ocdtrekkie>
It has an upload button, and it web publishes.
<kentonv>
Hacker CMS would be awkward for large uploads. Also it will store two copies of all your data.
<kentonv>
if you click on any of the uploaded files in the file list, it will awkwardly download the whole file and attempt to display it in the editor window
<kentonv>
you'd have to maintain your own directory listing
<kentonv>
but yeah, it could _basically_ work
gopar has joined #sandstorm
<ocdtrekkie>
Well, I never said it was a good idea. :P
<ocdtrekkie>
Though in the proud spirit of creating Sandstorm apps by deleting code, you could probably delete a few things to make it a simple upload container. ;)
bb010g has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
gopar has quit [Quit: Leaving]
ArcTanSusan has joined #sandstorm
joshbuddy has joined #sandstorm
ArcTanSusan has quit [Quit: ArcTanSusan]
erikoeurch has joined #sandstorm
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
jadewang has quit [Remote host closed the connection]
maurer has quit [Ping timeout: 264 seconds]
maurer has joined #sandstorm
mort___ has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
mort___ has quit [Quit: Leaving.]
mort___ has joined #sandstorm
erikoeurch has quit [Ping timeout: 245 seconds]
erikoeurch has joined #sandstorm
erikoeurch has quit [Ping timeout: 276 seconds]
natea has joined #sandstorm
natea has quit [Quit: natea]
natea has joined #sandstorm
natea has quit [Quit: natea]
erikoeurch has joined #sandstorm
joshbuddy has joined #sandstorm
mort___1 has joined #sandstorm
mort___ has quit [Ping timeout: 265 seconds]
jeffmendoza has quit [Remote host closed the connection]
ArcTanSusan has joined #sandstorm
ArcTanSusan has quit [Client Quit]
jeffmendoza has joined #sandstorm
jleo has joined #sandstorm
mort___1 has quit [Ping timeout: 265 seconds]
natea has joined #sandstorm
gopar has joined #sandstorm
mort___ has joined #sandstorm
mort___ has quit [Quit: Leaving.]
<paulproteus>
Morning all
<paulproteus>
zarvox: Around for a "quick" question?
<paulproteus>
I am thinking that it would be nice if vagrant-spk were to set an environment variable (e.g. IS_SANDSTORM=yes) or do some other thing so apps can detect reliably if they're on Sandstorm.
<paulproteus>
Oh, right, the last time I discussed this with people e.g. kentonv, we decided apps could do this via a setting in their own settings file.
<paulproteus>
The reason I want this, fwiw, is that I can foresee lots of apps having the following security bug. On the public Internet, the app could respect the X-Sandstorm-Permissions header, even though the header came from an attacker.
bb010g has quit [Quit: Connection closed for inactivity]
<paulproteus>
Having there be an app-specific setting should take care of this, although I'm still a little concerned that app developers will get it wrong.
mort___ has joined #sandstorm
dwrensha has joined #sandstorm
mort___ has quit [Client Quit]
jadewang has joined #sandstorm
<ocdtrekkie>
paulproteus: Wouldn't that be almost a non-Sandstorm problem though?
<paulproteus>
Sure -- this would be a non-Sandstorm problem.
<paulproteus>
I want to make sure that when Sandstorm app packagers try to get their changes into the upstream projects, then the upstream project is not harmed by this. (-:
<zarvox>
paulproteus: that's sounds like more of a supervisor thing than a vagrant-spk thing, but sure, I could believe that letting the grain know it's in a grain would be worthwhile.
<paulproteus>
I think for now I'm going go with "App packagers are supposed to add a setting to their app's settings file, and at runtime look at that setting to enable Sandstorm-related features"
<ocdtrekkie>
I endorse nobody caring about IE8. Android below 4.3... I'd need to see where the metrics are at. I think 4.4 is the vast majority of users now.
<ocdtrekkie>
4.1 and 4.2 still have a pretty non-trivial market segment. :/
<ocdtrekkie>
40% of Android users are below 4.3, and that's only counting Google-blessed Androids.
<zarvox>
that said, Chrome for Android has a way larger market share than Android Browser, so maybe it's okay?
<zarvox>
Oh, and all versions of IE don't properly scale SVGs.
<zarvox>
Which I guess is what we were seeing on the homepage in IE9.
<zarvox>
I should bike to the "office"
<paulproteus>
I'll be remote (in SF, coworking at Heavybit) today, for what it's worth.
<paulproteus>
Oh yeah I was going to send an email to that effect
mort___ has joined #sandstorm
<ocdtrekkie>
What's Heavybit?
<ocdtrekkie>
I guess PNGs should survive while SVGs are unhappy with 40% of Androids plus who knows how many versions of IE.
<ocdtrekkie>
It's open source, so I guess if you wanted to send all of your commands to a Sandstorm grain, you could.
<ocdtrekkie>
But I imagine it would be extremely easy for this to end up sending sensitive factoids to whatever server you use.
<zarvox>
Yeah. There was a startup doing a thing that watched all your keyboard IO into terminals to supposedly try to help you write better code/learn from what other people at your company do.
<zarvox>
They seemed pretty nonchalant about the privacy implications of capturing passwords and sending them to their centralized service.
erikoeurch has quit [Ping timeout: 272 seconds]
<zarvox>
I was horrified.
<ocdtrekkie>
Now I got an invite.
<ocdtrekkie>
Oasis is a good name, by the way. Fits the theme, allows easy distinguishment between the platform and the service, etc.
<paulproteus>
Requesting your sanit-check on this. Also I think this is ready for jadewang
<jadewang>
looking now
<paulproteus>
Also wow that felt like marathon.
<paulproteus>
Quoth the tutorial:
<paulproteus>
Use vagrant-spk to create a package definition file for your app
<paulproteus>
Every Sandstorm package needs to declare its name. It does this in a sandstorm-pkgdef.capnp file. (capnp is short for Cap’n Proto; for the purpose of this tutorial, Cap’n Proto is a configuration file format that is easy for Sandstorm to parse.)
<paulproteus>
</quote>
<paulproteus>
After this gets a sanity-check, I plan to replace Packaging-Tutorial with it.
<paulproteus>
phildini: You might possibly enjoy Use vagrant-spk to create a package definition file for your app
<paulproteus>
Every Sandstorm package needs to declare its name. It does this in a sandstorm-pkgdef.capnp file. (capnp is short for Cap’n Proto; for the purpose of this tutorial, Cap’n Proto is a configuration file format that is easy for Sandstorm to parse.)
<paulproteus>
And dwrensha it maybe explains some things.
<jadewang>
well, I'm just going to follow the steps
<jadewang>
sanity check may take a bit of time
<paulproteus>
That's fine with me. jadewang fwiw this is PHP-focused; I need to write the Meteor-specific addendum next.
<jadewang>
ah
<jadewang>
ok, i'll start doing things and hopefully by the time I need meteor-specific things, it'll be available :P
<paulproteus>
I believe I actually do recommend you read through this and work through it; once you've ... yeah exactly (-:
<paulproteus>
Taking a brief break, then will attempt to write the meteor addendum
<paulproteus>
jadewang: If you're willing to tell me about any confusions you run into, that'll be glorious.
<paulproteus>
Feel free to do that in real time, or to batch them.
natea has quit [Quit: natea]
mort___ has joined #sandstorm
<jadewang>
oh right
<jadewang>
missing line breaks
<jadewang>
starting with cd ~/projects
<jadewang>
if you're not paying attention and just copy/pasta
<jadewang>
you end up in an ... ahem ... interesting state
mort___ has quit [Quit: Leaving.]
<paulproteus>
Yeah )-:
<paulproteus>
I think it's a problem in Hacker CMS; won't be a problem on e.g. github wiki. Sorry about that.
<ocdtrekkie>
Okay, so I finally skimmed through vagrant-spk. Still haven't actually tried it, but skimmed the repo of it.
<ocdtrekkie>
Will having all the framework specific stuff in one file eventually be unruly?
<ocdtrekkie>
Also, can you make it work with Go? I tried playing with a Go app, but the setup for Go does not seem simple.
<paulproteus>
Yeah, we can probably make it work with go!
<ocdtrekkie>
I expect to apt-get things and have them work. This is not true of Go.
<paulproteus>
The "good" news is that the go package manager should be reasonably easy to support.
<paulproteus>
I would love to see a package for Hugo in particular.
<paulproteus>
(go-based blogging tool)
<ocdtrekkie>
So does Vagrant like store a VM for each app, or create it every time to run it, or what? And how long does it tend to take to start up?
<ocdtrekkie>
vagrant-spk to be more accurate.
<paulproteus>
A VM for each app. Haven't measured startup time yet; I estimate 20 sec.
<paulproteus>
Maybe 120 sec.
<ocdtrekkie>
How big are these VMs?
<ocdtrekkie>
For like a basic PHP app.
<paulproteus>
Probably ~500MB
<paulproteus>
Haven't measured carefully.
<paulproteus>
There's some degree of copy-on-write.
<ocdtrekkie>
My concern being that my 'playground' is a 40 GB VM.
<paulproteus>
I think that'll basically be fine, but yeah, I can see that eventually being a problem possibly.
<ocdtrekkie>
(I still have no idea if vagrant-spk can even run inside a VMware VM.
<paulproteus>
It can in theory. There are a couple of ways to make it work. We can document them.
ragesoss has quit [Quit: No Ping reply in 180 seconds.]
<ocdtrekkie>
Please do.
ragesoss has joined #sandstorm
<paulproteus>
++
<ocdtrekkie>
Though I think in my case where I have a specific dev VM, vagrant-spk probably isn't ideal. The biggest part that excites me is the platform-specific setups for PHP and stuff.
<paulproteus>
Yeah. FWIW the best way to make that work will presumably be libvirt's lxc backend.
<paulproteus>
waaaah why does uploading an app to local.sandstorm.io take ten minutes waaah
<paulproteus>
It did eventually succeed, which is important.