<dwrensha>
`make continuous` reduces the need to recompile dependencies
<dwrensha>
hm... I'm getting a build error with CXX=g++
<dwrensha>
it's possible that fiddling with flags could get it to work.
<kentonv>
yeah we don't ever attempt to build with GCC so it probably won't work
<kentonv>
and Ekam is the only build system, and it's only set up to build dependencies directly
<cstrahan>
kentonv: is there a way to make Ekam generate a Makefile?
<kentonv>
no... that's a feature I wanted to implement but never got around to
<cstrahan>
gotcha.
<kentonv>
is this because you want to build a nix package?
<cstrahan>
yep!
<cstrahan>
trying to come up with a minimally hacky solution.
<cstrahan>
ideally, we'd be able to build with already built deps
<cstrahan>
and then dynamically link to those.
neynah has joined #sandstorm
<cstrahan>
building clang right now. i'll try out maurer's approach when that's done.
<maurer>
(My approach, fwiw, breaks a bunch of nix packaging guidelines, but at least gets through the ekam build)
<maurer>
(the thing I wasn't able to deal with was meteor, which means I couldn't get a frontend)
<cstrahan>
right.
<maurer>
Since cstrahan got meteor packaged, maybe we can get a frankenstein of a package working
<cstrahan>
ha!
<cstrahan>
we already package some binary-only stuff when no other alternative exists (e.g. proprietary stuff), so this certainly isn't the worse scenario.
<kentonv>
hmm, this is somewhat awkward in that people who install this package won't be on our auto-update track
<cstrahan>
I think someone on NixOS would want to avoid precisely that :)
<maurer>
kentonv: Yeah, this is generally considered desirable in a package that autoupdate features are disabled
* asheesh
waves groggily.
<maurer>
kentonv: Chromium gets this neutered out, mendeley gets this stopped, etc.
<kentonv>
well... my personal opinion is that that's a really bad idea. I understand others may disagree, though.
<maurer>
kentonv: Do you know of an example of a package from a common distro (e.g. debian, ubuntu, gentoo, arch, maybe other similar ones) which leaves autoupdate in place?
<cstrahan>
on the other hand, we have an option to automatically update one's entire system at a set interval.
<kentonv>
no, and I hate that chrome doesn't auto-update on my machine
<maurer>
Yeah, usually that's what's going on is that the package manager way is that you run all updates through the package manager
<maurer>
and if you want it to auto update, you tick that box on the package manager instead
<cstrahan>
even then, though, determinism (per system update) is preserved, as well as deterministic rollback
<maurer>
kentonv: Are you using debian?
<kentonv>
yes, I'm on debian
<maurer>
kentonv: If so, you may want to check out the unattended-upgrades package
<kentonv>
but that's not what I want
<kentonv>
debian is not good at shipping updates that don't break everything
<asheesh>
(Life can be more complicated than that, and I'm too sleepy (east coast time) to offer more detailed advice.)
<maurer>
kentonv: In any case, unattended-upgrades also allows you to filter which packages get unattended upgraded
<kentonv>
asheesh: yeah I should probably do that, but more importantly, IMO, everyone should do that
joshbuddy has quit [Quit: joshbuddy]
<kentonv>
maurer: auto-updates are important for the user for their security. But they're also important for the platform because it means developers don't need to be compatible with old versions.
<kentonv>
so an option where only some users auto-update doesn't cover the latter point
<maurer>
kentonv: I'd suggest the way to deal with that is in the short term, tell devs to only write against the latest version, and people who are packaging it will just have to keep bumping versions if they want to take new apps/new app versions
<maurer>
kentonv: in the long term, you'd probably want a stable/LTS version which is semi static that people could write against, but my understanding is that the features are not nearly to the point where that's a useful plan
<asheesh>
kentonv: Yeah, agreed re: everyone
<kentonv>
eventually we'll probably have stable/beta/dev channels like chrome
<maurer>
kentonv: I mean, my opinion on unattended-upgrades is that it is a great default for desktop/laptop machines
<maurer>
and a terrifying idea for servers
<maurer>
In any case, I understand that you want to do things differently, but it seems like it should be unsurprising that any packaged sandstorm would not autoupdate
<maurer>
given that even packages like chrome, released by google, do not do so
<kentonv>
chrome auto-updates on every platform except Linux
<maurer>
Yeah, because on linux there's a package manager to do the update
<cstrahan>
i appreciate the desire to protect users by rolling out binary updates automatically, but from the perspective of a package maintainer, its irksome being unable to take control of security when binary updates don't roll out in a timely fashion
<maurer>
On Android and iOS, they also don't autoupdate chrome
<maurer>
they use the app store to do it
<cstrahan>
that and not knowing what was statically linked in
<cstrahan>
it's trivial to update all packages (at least in a Nix/Guix world) when a new CVE is announced
<cstrahan>
but only when we have the ability to rebuild stuff.
<kentonv>
cstrahan: I think this ultimately turns into a debate over who is likely to be more responsible, the distro maintainer or upstream. I think in a lot of cases, it is absolutely right to place trust in the distro maintainer, but I think in a few cases like Chrome, upstream is more responsible (by virtue, perhaps, of having way more resources).
<kentonv>
like, if I had the option to run Chrome in a container where Google maintains all of its dependencies and auto-updates the whole thing, I'd definitely choose that, and use Debian for everything non-chrome. Chrome is by far the biggest attack surface on my desktop.
frigginglorious has joined #sandstorm
joshbuddy has joined #sandstorm
<kentonv>
well, I feel bad for being discouraging here. :/
<maurer>
I mean, it's not going to go well if people packaging it have friction with upstream, so it's important to discuss
<maurer>
even if the conflict feels a little painful
<maurer>
asheesh: Maybe you have something to add from the debian side if you're not too sleepy to weigh in?
<asheesh>
[6~[6~[6~I dunno.
<asheesh>
~.
<kentonv>
I think this end up looking a lot like firefox vs. iceweasel, actually
<kentonv>
on that note, at some point we are probably going to make our repository build with different branding by default -- e.g. Duststorm instead of Sandstorm. Official builds will switch the branding back to Sandstorm, but our trademark rules will prohibit using that branding on non-official builds (much like Firefox).
<dwrensha>
"Silicate"
<kentonv>
I'm open to suggestions on the alt brand. :)
<dwrensha>
Nimbosilicate
<dwrensha>
Stratosilicate
eternaleye has joined #sandstorm
<kentonv>
I do feel like it should have some component of the original name so that people can tell they are closely associated, but not the same.
<kentonv>
I am not against people packaging duststorm (or whatever) if they want. I do worry that there may be friction if it turns out we need to overhaul our build system, though.
<cstrahan>
no worries re: discouragement
<kentonv>
you *might* be able to get away with a makefile that passes the proper CXXFLAGS and LIBS to ekam such that all the libraries get linked in. This would cause every binary to link every dependency library even if it doesn't use them, but maybe that's not a big deal.
<dwrensha>
Blandstorm
<cstrahan>
lol
<kentonv>
haha
<kentonv>
I suppose a distro-friendly package would not want to do the self-container thing, which may mean we need a code path that avoids that
<cstrahan>
kentonv: we already have a way to inject CXXFLAGS and such. our $CC is actually a wrapper that looks for $NIX_CXXFLAGS and such.
<kentonv>
cstrahan: right, but at the same time you need to edit the makefile to *not* auto-download capnproto and other dependencies
<dwrensha>
Offbrandstorm
<kentonv>
... tempting
<cstrahan>
kentonv: maurer's work patches that stuff out.
<cstrahan>
should I setting CXXFLAGS and LIBS (as env vars, I presume) with all of the deps "do the right thing"?
<dwrensha>
meet the Flintstorms
<cstrahan>
ha
<kentonv>
cstrahan: I don't know, I think you'll find that the "right thing" is to move away from the self-containerization entirely, but that'll require a bunch of work
<kentonv>
the Makefile basically does three things: (1) run ekam, (2) run meteor, (3) put the results and all their dependencies into a tarball to ship.
<kentonv>
probably you want to write a whole new Makefile that runs ekam in a different way, runs meteor in a different way, and then puts together a package that doesn't include dependencies.
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger has joined #sandstorm
larjona has quit [Remote host closed the connection]
coyotebush has quit [Ping timeout: 260 seconds]
coyotebush has joined #sandstorm
<frigginglorious>
Tonight I did a presentation on this new thing called Sandstorm for my local dev group.
<kentonv>
nice!
<kentonv>
how did it go?
<frigginglorious>
People liked it, I know at least one guy is a teacher, hes going to be using it in the classroom :)
<kentonv>
cool
<kentonv>
I've noticed educators have an unusual affinity for Sandstorm, and to be honest I'm not completely sure why that is.
<frigginglorious>
because of the applications that have been ported!
<kentonv>
like sharelatex?
<frigginglorious>
they are all perfect for small group collaberation.
<frigginglorious>
oh, i havent tried that one yet
<kentonv>
but I mean, small group collaboration happens everywhere, doesn't it? E.g. companies are composed of teams.
<frigginglorious>
Yeah, but it’s never done well :P
<kentonv>
I'm just trying to figure out why teachers latch on to this more quickly than, say, corporate office workers.
<kentonv>
not that I'm complaining, obviously. :)
<frigginglorious>
no, i know what you mean
<frigginglorious>
honestly, i work for a small company of about 60 people. I respect the people in charge, they are smart. Not everyone can say the same about where they work.
<frigginglorious>
But they don’t feel comfortable using a tool and investing any kind of thought into it unless they pay for it.
<frigginglorious>
the more it costs, the more they trust it. At least that is how it seems.
<kentonv>
hey we can help with that!
<kentonv>
:)
<frigginglorious>
I will see to it!
<kentonv>
we'll be releasing Sandstorm for Work in a month or two, probably at $15/user/month. Is that expensive enough? :)
<frigginglorious>
That should be about right
<maurer>
cstrahan: Only thing I can think of is maybe you're using a different clang?
<maurer>
cstrahan: I was using master last time I built this, and unstable nixos hasn't bumped in a while
<maurer>
what ere you building off of?
<cstrahan>
ah. clang 3.7.1
<maurer>
I think that's new enough :/
<maurer>
kentonv: Some of it may be that teachers are more likely to be empowered to pick technologies than officeworkers
<frigginglorious>
kentonv: as someone commented during the talk “they want SaaS so they can have someone to yell at when things go wrong”
<kentonv>
FWIW clang and G++ have some series ABI compatibility issues going on right now. Apparently GCC up an changed their ABI without really talking to anyone.
<kentonv>
frigginglorious: LOL, a decade ago it was "They don't want SaaS because they want someone to fire when things go wrong"
<maurer>
cstrahan: That might make sense, maybe what happened is I got something built against 3.6.*, you are building from 3.7.*, and need to bump the sandstorm hash
<maurer>
(or pass clang_36 to the function)
larjona has joined #sandstorm
<cstrahan>
dwrensha: thanks!
<cstrahan>
I've bumped the revs; maybe that'll do it.
<kentonv>
cstrahan: that test is notorious for failing depending on your network configuration, because getaddrinfo() has the absurd property that it will parse ipv6 addresses only if ipv6 is configured on some network interface.
<kentonv>
that said, I thought I fixed it
<kentonv>
cstrahan: are you using Cap'n Proto from master or 0.5.x release?
<cstrahan>
kentonv: master
<cstrahan>
since it looks like the Makefile pulls down master from each, I figured I'd use the lastest of everything for the least number of surprises.
<kentonv>
you definitely need to use master with Sandstorm
<kentonv>
that's awkward for packaging, though
<kentonv>
Sandstorm and Cap'n Proto are essentially developed together, but released on wildly different schedules...
Jan\ has joined #sandstorm
<kentonv>
I guess we should really release Cap'n Proto more often, but that requires keeping the Windows build updated. >_>
<cstrahan>
here's the line from the log: kj/async-io.c++:775: failed: DNS lookup failed.; params.host = 1.2.3.4; params.service = http; gai_strerror(status) = Servname not supported for ai_socktype
<cstrahan>
probably just need to patch out that test, since the build environment runs without network access.
<maurer>
cstrahan: Yeah, I'd say patch that out, since the build environment in the future won't even be able to touch network sockets iirc
<maurer>
kentonv: You may also have fixed it, if he's using my package description, it is "master at the time I grabbed sandstorm master"
<kentonv>
cstrahan: yeah if you have no network access then getaddrinfo() probably refuses to parse even ipv4, which will break the test. (The test doesn't actually do any networking, it just wants to parse an address... bleh)
<maurer>
Oh getaddrinfo
<maurer>
You are so terrible
<kentonv>
understatement
coyotebush has quit [Ping timeout: 260 seconds]
coyotebush has joined #sandstorm
<cstrahan>
wow, well `spk` just built.
<cstrahan>
a bit surprised it built so fast.
<kentonv>
there's honestly not a ton of C++ code in sandstorm proper if that's all you're building.
<cstrahan>
yeah, I just figured with building capnp/libsodium/libseccomp that it might take a bit longer.
<kentonv>
frigginglorious: Yay! Be sure to send it to community@sandstorm.io
<kentonv>
frigginglorious: oh, I see you tweeted it. That works too!
<cstrahan>
kentonv: what exactly is responsible for running grains? looking at run-bundle.c++, it looks like it's responsible for starting and supervising the meteor app / mongo / etc, manages config, drops privs & chroots and such... trying to figure out how much of I'll really need, if any.
<kentonv>
backend.c++
<kentonv>
implements backend.capnp
<kentonv>
yeah I guess it's possible that you could dump run-bundle.c++ entirely, and have some other binary that just runs the back-end, and then start up Node and Mongo separately.
<cstrahan>
cool - thanks!
<kentonv>
cstrahan: you'll need to replace the `sandstorm admin-token` command, but it basically just writes a random string to a file. You won't be able to support app development, but people mostly use vagrant-spk for that anyway, in which case they're using our whole VM image.
<cstrahan>
you've clearly done a whole lot of work make sandstorm self-contained. i feel a little dirty wanting to take it apart :P
<cstrahan>
kentonv: i'll probably try to keep the old exes functional - but that will require that I change the paths that point to directories under the package prefix, as those won't be writable.
<cstrahan>
that way one can still do development easily, and the package could (hopefully) still be useful outside of NixOS.
<cstrahan>
(perhaps asheesh could make use of it)
<kentonv>
cstrahan: also I'd advise not trying to support sandcats registration in a first attempt... that deeply depends on install.sh doing a bunch of work, and also relies on a weird approach to starting up Meteor (see meteor-bundle-main.js), all of which you could safely skip if you don't support sandcats.
<kentonv>
cstrahan: and technically Sandcats' ToS says you must run the official build of sandstorm, so...
<kentonv>
(not that we enforce that, but we don't want anyone complaining if we change the protocol and it breaks for them)
<cstrahan>
yeah, that looked a little intimidating. and good point about the ToS. i'm currently just focused on getting something working quickly.
<kentonv>
cstrahan: Well, you really aren't likely to be able to make local development (`spk dev`) work without incorporating a lot of stuff from run-bundle which probably doesn't apply easily to your environment. But we actually do tell everyone to use vagrant-spk these days so it seems moot...
<kentonv>
(I think I am the only person who still develops sandstorm apps using raw spk!)
<maurer>
kentonv: I've not made professional apps, but the two apps I wrote and have running on my personal sandstorm were made with raw spk
<kentonv>
maurer: by any chance are they in Rust? :)
<maurer>
kentonv: No, yesod (haskell webframework)
<elimisteve>
I, too, tried to get LetsEncrypt working, ran into the wildcard SSL issue, gave up, and then checked back later and found ^^that^^
tierce has joined #sandstorm
jadewang has joined #sandstorm
Salt_ has joined #sandstorm
dcb- has joined #sandstorm
zarvox has quit [*.net *.split]
azirbel has quit [*.net *.split]
Jan\ has quit [*.net *.split]
garrison has quit [*.net *.split]
citruspi has quit [*.net *.split]
Zertrin has quit [*.net *.split]
sprin has quit [*.net *.split]
iangreenleaf has quit [*.net *.split]
fkautz has quit [*.net *.split]
hunterm__ has quit [*.net *.split]
ckocagil has quit [*.net *.split]
coyotebush has quit [*.net *.split]
Salt has quit [*.net *.split]
dcb has quit [*.net *.split]
KCinJP has quit [*.net *.split]
sknebel has quit [*.net *.split]
msoucy has quit [*.net *.split]
nicolagreco has quit [*.net *.split]
sugarpuff has quit [*.net *.split]
_iwc has quit [*.net *.split]
coyotebush_ has joined #sandstorm
Zertrin__ has joined #sandstorm
zarvox has joined #sandstorm
asmyers has joined #sandstorm
msoucy| has joined #sandstorm
Salt_ is now known as Salt
_citruspi has joined #sandstorm
msoucy| is now known as msoucy
sprin has joined #sandstorm
sknebel has joined #sandstorm
synchrone has quit [Ping timeout: 258 seconds]
jadewang has quit [Ping timeout: 240 seconds]
garrison has joined #sandstorm
garrison has quit [Changing host]
garrison has joined #sandstorm
iangreenleaf has joined #sandstorm
Jan\ has joined #sandstorm
ckocagil has joined #sandstorm
_iwc has joined #sandstorm
Kamilion has joined #sandstorm
NhanH has joined #sandstorm
simonv3 has joined #sandstorm
hunterm__ has joined #sandstorm
bpierre has joined #sandstorm
bpierre has quit [Remote host closed the connection]
azirbel has joined #sandstorm
<axx_>
elimisteve: that does look cool, I'm just not a fan of running my own server on a .sandcats.io subdomain
<axx_>
I rather like the domain I was planinng on using it with ;)
frewsxcv_ has joined #sandstorm
msoucy has quit [Ping timeout: 250 seconds]
jadewang has joined #sandstorm
<elimisteve>
I see
jadewang has quit [Ping timeout: 240 seconds]
jon1012 has joined #sandstorm
jon1012 has joined #sandstorm
mulk_ has joined #sandstorm
mulk_ is now known as mulk
mulk has quit [Client Quit]
mulk has joined #sandstorm
axx_ has quit [Ping timeout: 240 seconds]
joshbuddy has joined #sandstorm
joshbuddy has quit [Client Quit]
axx_ has joined #sandstorm
hunterm__ has quit [Ping timeout: 268 seconds]
hunterm__ has joined #sandstorm
fkautz has joined #sandstorm
bpierre has joined #sandstorm
frigginglorious has joined #sandstorm
indiebio has quit [Quit: No Ping reply in 180 seconds.]
indiebio has joined #sandstorm
mulk has quit [Remote host closed the connection]
mulk has joined #sandstorm
sugarpuff has joined #sandstorm
<asheesh>
chilts: ohai
<asheesh>
chilts: Does VirtualBox work at all, on that machine? My guess is no, fwiw.
<asheesh>
For example, on a cloud VM, VirtualBox usually won't work.
<asheesh>
And similarly, on a laptop with VT disabled in the BIOS (which is easy to enable again), VirtualBox won't work at all, but we rely on VirtualBox (at the moment) for system emulation.
jadewang has joined #sandstorm
<asheesh>
kentonv: I do think that nix+spk would make really good tooling *within* vagrant-spk, fwiw.
<asheesh>
Also good morning, all.
indiebio has quit [Quit: No Ping reply in 180 seconds.]
<asheesh>
axx_: Did you get your DNS issue sorted out? They seem OK from where I sit, fwiw.
<asheesh>
maurer: I'm excited about your random personal productivity apps!
sugarpuff has quit [K-Lined]
fkautz has quit [K-Lined]
<asheesh>
maurer: The fact that you could make them and still run them is pretty exciting for me.
<asheesh>
frigginglorious: I see your talk video! I'll try to watch it today! So excited that you were able to do that.
indiebio has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
<asheesh>
kentonv: w/r/t education & sandstorm: I think this is because there's often more trust between tech-minded educators and their IT departments, and vice versa, the IT departments do want to be helpful. And similarly educators have a little more ability to be like "screw it, I'm going to do this tech project by myself" without the org crying foul.
<frigginglorious>
asheesh: thanks a ton for reaching out, it was great to get up in front of people and talk. Also, it was fun to give myself a crash course on Sandstorm :D
<asheesh>
(I see maurer has the same thought.)
<asheesh>
w/r/t kentonv & cstrahan & maurer & nix packaging: Whew, y'all have a lot to think about.
<asheesh>
...also I see that my attempt to say nothing did not work, and I typed a literal ~. into the channel. Oh well.
<asheesh>
(also I like "blandstorm")
<dwrensha>
asheesh: I interpreted your ~s as signifying snoring.
<asheesh>
Hah!
<axx_>
asheesh: haven't tried since I mentionned it earlier
<axx_>
but no, it didn't seem to be working
<axx_>
I'll try again
<asheesh>
They were me trying really hard to disconnect this window from irssi because I knew I was too tired to say anything useful.
<asheesh>
FWIW I'd like to see a way that distros can distribute "Sandstorm" not "Blandstorm" if they agree to something-or-other.
<asheesh>
Seems to say it works, as does my laptop.
<asheesh>
Do you get the big red "oh no wildcard DNS is broken!" message in /admin ?
<axx_>
everything looks fine :-/
<axx_>
asheesh: yup
<asheesh>
Fascinating. What port are you running Sandstorm on?
<axx_>
“WARNING: This server seems to have its WILDCARD_HOST misconfigured. Until you fix it, you will not be able to use any apps. Learn more. You'll need to adjust DNS or edit the sandstorm.conf file. Once you have addressed the issue, reload this page. If you're still having problems, email us at support@sandstorm.io. ”
<asheesh>
synchrone: Email community@sandstorm.io with a link to an app you've made, and your Oasis account email address, and I'll make sure it happens.
<asheesh>
Obviously I remember who you are, but "link to an app you've made" (e.g. the github repo for the radicale thing) (or a link to a grain) just so we have the info in one place (the email).
<synchrone>
am I eligible before it hits the appstore?
<asheesh>
Since your app is fascinating, complicated, and basically ready, yes.
asmyers has quit [Ping timeout: 240 seconds]
<synchrone>
well, wasn't really complicated... i just smashed some FOSS pieces together
<asheesh>
well, wasn't really complicated... we just configure the C++ compiler to emit a binary that when executed, runs a novel product called sandstorm
<asheesh>
By which I mean: you can downplay how cool your app is, if you want, but I still think it's great.
<gillisig>
asheesh, synchrone: You guys are making me very curious about this app!
axx_ has joined #sandstorm
<asheesh>
It's CardDAV & CalDAV via Radicale.
<asheesh>
Also synchrone in American English, at least, you should probably use a / not a \ to separate the two - CardDAV/CalDAV vs. CardDAV\CalDAV.
<asheesh>
As a random aside.
<synchrone>
so that's why they chose \ as escape char %)
<asheesh>
Yeah - the \ character means basically nothing in English, but / does.
<synchrone>
also, I tried to re-purpose apple's CalDAV Tester set of tools from their contact server suite...
puck2 has joined #sandstorm
<asheesh>
Ooh, very nice.
<asheesh>
I know at least one of hte ContactServer contributors!
<asheesh>
s/hte/the/
<asheesh>
How did that turn out for you?
<synchrone>
it's a little too opinionated about url layout ...
<synchrone>
could be re-configured, some optional features cut off, etc
<synchrone>
was able to have it passing some tests
<asheesh>
api-offer/inf-it-integration.js: var petname = "CalDAV\\CardDAV Sync";
<asheesh>
There we go, that's the one I saw.
<synchrone>
ah, okay
jadewang has joined #sandstorm
<puck2>
asheesh: the missing headers do not pose any risk to self-hosters that are using the subdomains?
<synchrone>
also, to always have the control over application once it hits the appstore the only file I must backup is ~/.sandstorm/sandstorm-keyring, right?
<asheesh>
puck2: Self-hosters use sandcats.io subdomains, and sandcats.io has no user-controlled content.
<asheesh>
*.sandcats.io does, but that's controlled by each self-hoster, and sandcats.io is also in the public suffix list.
<asheesh>
synchrone: I believe ~/.sandstorm/sandstorm-keyring is sync'd between the Vagrant VM and your own machine, but yes, that is the file you would need.
<asheesh>
puck2: Perhaps you can submit a patch to securityheaders.io to not check hosts that are in the public suffix list, and/or to support a way for a site to indicate it contains no user-controlled content, and therefore doesn't need these headers.
<synchrone>
... for the offchance laptop transforms into a pumpkin and I'd need to restore
<asheesh>
+1, backing up that file is a pretty seriously good idea.
jadewang has quit [Ping timeout: 248 seconds]
<synchrone>
good idea to have a reminder to backup the keyring in the docs
dcb- has quit [Ping timeout: 268 seconds]
<asheesh>
The main thing I want to do is add that to 'vagrant-spk upload' in the near future.
<asheesh>
IMHO that's when it matters.
<asheesh>
Hilariously we do ask people to backup the key when they do 'spk init' but that's not the time that it really matters.
msoucy has joined #sandstorm
<synchrone>
by the time they're done with their app, they have long since forgotten about it
<asheesh>
Indeed.
dcb has joined #sandstorm
<puck2>
asheesh: i'm not knowledgeable enough to assess how important the missing headers are, but i submitted your suggestion to the project head (Scott Helme)
<asheesh>
Cool!
|jemc| has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
fkautz has joined #sandstorm
sugarpuff has joined #sandstorm
KCinJP has joined #sandstorm
<asheesh>
Howdy KCinJP
<asheesh>
And hi all the rest of y'all, too.
Salt has quit [Ping timeout: 268 seconds]
jadewang has joined #sandstorm
synchrone has quit [Quit: Leaving.]
maurer has quit [Read error: Connection reset by peer]
maurer has joined #sandstorm
synchrone has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
Salt has joined #sandstorm
Salt has quit [Ping timeout: 268 seconds]
wolcen has joined #sandstorm
Salt has joined #sandstorm
xet7 has quit [Ping timeout: 240 seconds]
frigginglorious has joined #sandstorm
Salt has quit [Ping timeout: 268 seconds]
xet7 has joined #sandstorm
puck2 has quit [Quit: Leaving]
Salt has joined #sandstorm
xet7 has quit [Ping timeout: 240 seconds]
Salt has quit [Ping timeout: 268 seconds]
hunterm__ has quit [Ping timeout: 268 seconds]
Salt has joined #sandstorm
funwhilelost has joined #sandstorm
xet7 has joined #sandstorm
hunterm__ has joined #sandstorm
funwhilelost has quit [Client Quit]
mulk has quit [Remote host closed the connection]
azirbel has quit [Ping timeout: 240 seconds]
NhanH has quit [Ping timeout: 240 seconds]
jadewang has joined #sandstorm
coyotebush_ has quit [Quit: No Ping reply in 180 seconds.]
Zertrin has quit [Remote host closed the connection]
digitalcircuit has quit [Remote host closed the connection]
<cstrahan>
IRC is a problem that I'd love to tackle with Sandstorm
<cstrahan>
Right now, I have an account with IRCCloud, but I'd love to have a FOSS solution running as a grain
<cstrahan>
Is the requisite background processes support on Sandstorm's road map?
<cstrahan>
(Because, ideally, I would be able to keep logs of each channel, regardless of whether or not I'm viewing the grain)
wolcen has joined #sandstorm
<asheesh>
cstrahan: in a mtg atm, but basically: yes, that's on the roadmap!
<cstrahan>
asheesh: very cool! i'll be pretty stoked when I can replace IRCCloud :P
Guest28848 has quit [Changing host]
Guest28848 has joined #sandstorm
<cstrahan>
(I mean, they're a great service, but I'd prefer to have better control over my data)
Guest28848 is now known as preilly
<asheesh>
+1
bodisiw has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
joshbuddy has joined #sandstorm
<mrdomino>
asheesh: can you chat on the stream? have you used the capability link I DMed you?
neynah has joined #sandstorm
<asheesh>
mrdomino: I did, but I don't know if I bound it to my account.
<asheesh>
I was on my phone earlier; I'm now on my laptop again.
<asheesh>
BTW I *love* listening to mrdomino radio from my phone.
<asheesh>
OK, from my laptop, it seems to be true that I can share all permissions, including "All Access" (what is this, Google Play?)
<asheesh>
What I type into chat doens't seem to show up, though.
<dwrensha>
being able to share all permissions doesn't mean anything
<asheesh>
Oh, then is there a way to see my own permission level?
<asheesh>
I guess that's what you're working on this week?
<asheesh>
Switching Identities in case that makes a difference.
<asheesh>
OK, one of my identities can chat, and the other can't.
<asheesh>
At this point, I want to revoke that other identity because its only purpose in being able to access the grain is to confuse me.
<dwrensha>
asheesh: you can see your permissions from the javascript console, e.g. Sessions.findOne({}, {fields: {permissions: 1}})
<dwrensha>
I think you would need to use the `cachedViewInfo` field in Grains to interpret it, though.
<asheesh>
Can I disconnect the grain from my other, worse identity?
<asheesh>
I guess I could carefully sharing-link the grain to my other identity and xfer the permissions there too but that seems like missing thepoint of multiple identities.
<dwrensha>
asheesh: we could craft a command in your javascript console to do that...
<asheesh>
Also this wifi network I'm on has terrible bandwidth, which is no one's fault, but may result in some typos.
<mrdomino>
being able to share all permissions doesn't actually?
<dwrensha>
mrdomino: it's a UI bug
<mrdomino>
ok rad
<dwrensha>
we should hide the options the don't make sense
<mrdomino>
fwiw i've also been confused by grains showing up multiple times for linked identities
<asheesh>
Many of these things are suffering from having the specific, preferred workflow not discussed/documented/decided yet, fwiw, so mrdomino suggestions on that (probably serialized eventually into a GitHub issue) is what we need for things like that.
<asheesh>
Even if things aren't possible, it's good to have that written down somewhere.
xet7 has quit [Ping timeout: 240 seconds]
<mrdomino>
yeah, but i can cut out some steps and just stick it on the issue :-p
greg-g has left #sandstorm [#sandstorm]
rustyrazorblade has joined #sandstorm
<chilts>
asheesh: thanks, I'll try VirtualBox on it's own (not that I know how, but I'll figure it out)
<chilts>
it's just my laptop, so perhaps that BIOS setting isn't right
<asheesh>
Yeah, it required me to fiddle a switch on my laptop, chilts
<chilts>
thanks
kecors has joined #sandstorm
<chilts>
am back in my workday, so I'll have to try again tonight - thanks for your help
<chilts>
ooh, I could turn that off (as a test) then?
<asheesh>
I'm curious if you'd test out those vb.customize options, in .sandstorm/Vagrantfile , depending on how far deep into this rabbit hole you're willing to dig.
<asheesh>
Yeah,exactly.
<chilts>
hah
<asheesh>
The last comment there (5 specific vb.customize lines) is promising hypothetically.
<asheesh>
Then, 'vagrant-spk halt' and 'vagrant-spk destroy' then 'vagrant-spk up'.
<chilts>
do I just put those 5 lines at the bottom of .sandstorm/Vagrantfile
<chilts>
?
<chilts>
or somewhere in the middle
<chilts>
sorry, I'm no familiar with VirtualBox or vagrant much
<asheesh>
np. You look for this line:
<asheesh>
config.vm.provider :virtualbox do |vb, override|
<asheesh>
and you see there's a bunch of vb.foo = bar
<asheesh>
So you add these other vb.foo = bar
<chilts>
ah yes
<asheesh>
lines within there, indented properly, and then you do the halt & destroy & up
<chilts>
ok
* chilts
will report back
<asheesh>
It's super useful to know if that works.
<chilts>
doing up now
<chilts>
doesn't seem to be crapping out like last time, still waiting, hopefully it's not hung
<asheesh>
Could be! We'll see! Fascinating!
<asheesh>
Oh, you also need to make sure you set the # of CPUs to 1, apparently.
<asheesh>
vb.cpus = 1
<asheesh>
to achieve that.
<chilts>
done that too
<chilts>
no, didn't work
<chilts>
lemme see
<chilts>
yeah, somehow hung or timed out : Timed out while waiting for the machine to boot.
<asheesh>
You can try running the VirtualBox GUI and see if it shows something useful.
<chilts>
is that virtualbox --something?
<chilts>
maybe $VBOX_GUI_DBG_ENABLED
<asheesh>
Just virtualbox (enter)
<asheesh>
In my experience, anyway.
<chilts>
vb.gui = true // should also work :)
<asheesh>
er, OK (-:
<chilts>
got the gui up now, will do the halt, destroy and up again
synchrone has quit [Ping timeout: 244 seconds]
<asheesh>
Keep in mind, this is definitely possibly hopeless! (-:
<zarvox>
you'll also need to have libvirt/libvirtd installed + configured, which may involve removing some of the permissions-blocking things from the global configs
<zarvox>
(on Fedora 23, the default vagrant provider is libvirt)
<zarvox>
Also I think you have to modify the box file with a vagrant plugin called vagrant-mutate
<zarvox>
I should probably write all this down somewhere
<chilts>
heh, ok, this is getting me deeper out of current work ... so I might have to try this later on :)
<chilts>
sorry guys, but thanks for both of your help so far
* chilts
is determined to get it to work though, so he'll be back
<zarvox>
No worries, and I'll see if I can't get this written up some time so that people who aren't me can actually use it :)
<zarvox>
maybe blur day!
<chilts>
that would be awesome if there was something I could follow
<chilts>
blur day?
<asheesh>
blur day == friday work on whatever you want not quite literally whatever you want day
<zarvox>
Monday through Thursday are typically "focus days", where we try to focus on feature work, whereas Friday is typically "blur day" where you do random things/fix bugs/do productive experiments
<chilts>
oh cool, sounds like CockroachDB (a recent blog post mentions the same thing)
<chilts>
and also, not quite 20% time because still somewhat related to work :)
amyers has quit [Ping timeout: 240 seconds]
notevil has quit [Quit: poof]
bodisiw has quit [Quit: This computer has gone to sleep]
rustyrazorblade has joined #sandstorm
<phildini>
I super wish I could have alternatives to newrelic, loggly, etc, that I could host on sandstorm and point my various other websites at.
<chilts>
asheesh: for things like file uploads, I was going to send them to S3, but perhaps I just store them on the filesystem ... I'm kinda assuming this because it says somewhere that Sandstorm automatically backs up grains. Is that a feature to be exploited like this?
<chilts>
ie. the 'Sandstorm' way
<chilts>
I guess I could _also_ send them to S3 for backup
|jemc| has quit [Ping timeout: 244 seconds]
neynah has joined #sandstorm
<asheesh>
chilts: Typically the filesystem is best
<asheesh>
Reasons: (1) Using the filesystem makes "grain backup" work properly. (2) Your app "doesn't have access" (*) to S3 anyway, so it's not clear how you'd send it all the way over there. (3) Now S3 is involved in the security story of your app.
<asheesh>
*. You can use the httpGet feature of Sandstorm to do this if you want, but it's "pre-deprecated", which is to say, it'll require a user interaction before the app is allowed to do that in the future.
<zarvox>
We may some day expose some concept of "object storage" to apps. But for now, use the FS.
<asheesh>
Anyway, that's the general idea, chilts, curious for your thoughts.
frigginglorious has quit [Ping timeout: 276 seconds]
wolcen has joined #sandstorm
rustyrazorblade has quit [Quit: rustyrazorblade]
wolcen has quit [Ping timeout: 240 seconds]
jadewang_ has quit [Remote host closed the connection]
jadewang has joined #sandstorm
kecors has quit [Quit: Leaving]
<chilts>
asheesh: you know, that all sounds reasonable. In fact, it just cements for me the security ideas behind Sandstorm, so I'm totally ok with that.
<chilts>
Makes it easier anyway, I've already implemented it to the filesystem
<chilts>
and confirms to me what I thought. Originally sending to S3, then I thought, hey I should just save it locally - so you've confirmed my suspicions.
<chilts>
I'm sorry, I keep asking questions - and always thankful for your answers
<asheesh>
No worries at all. It's nice to see people thinking out loud.
<chilts>
hah, I have another question! :) In the past I've configured the domain I am on in an environment variable (such as MYPROJECT_NAKED_DOMAIN) ... but I guess with Sandstorm the domain you're serving is essentially whatever is in the 'Host:' header.
<chilts>
Does that sound like where I want to get it from (if I need to create a fully-formed URL in the application to show the user)
<dwrensha>
chilts: X-Sandstorm-Base-Path
<chilts>
ah cool
<chilts>
haven't hit upon that in the docs yet, I need to read more