<zarvox>
XgF: is it -fsanitize=address -fno-omit-frame-pointer?
<zarvox>
in both your compiler and linker flags
<XgF>
I suppose I should say: I've done that, and now I need the asan runtime library, theres "libasan0", "libasan1" and "libasan2" in the package repository, all of which appear to have GCC version numbers, but I can't find one from LLVM, so I'm a bit lost here
<ocdtrekkie>
In fairness, I haven't successfully migrated off Gmail yet, so even GCE is an upgrade in privacy for now.
<zarvox>
Oh. Are you using a distro LLVM toolchain, or one you built yourself?
<ocdtrekkie>
But I'd hope at some point it becomes viable to use a different provider.
<XgF>
zarvox: I'm using the one LLVM.org builds and stuffs into an apt repo nightly. I'm beginning to suspect they dont stuff asan into said apt repo :(
<ocdtrekkie>
Sandstorm could even offer on different hosts or in different countries at a different rate. Though I know you're hoping third parties do some of that.
<zarvox>
XgF: Ahhh. I'm looking at the Fedora 22 packages, and libasan is a separate package, which provides /usr/lib64/libasan.so.2
natea has joined #sandstorm
<XgF>
Which is all fine and dandy but clang is looking for /usr/lib/llvm-3.7/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan_cxx-x86_64.a :S
<zarvox>
Ahh. On F22, that's provided by the clang package.
<kentonv>
ocdtrekkie: section 5.2 of Google Cloud ToS says they won't use our data for anything other than providing our service: https://cloud.google.com/terms/
<ocdtrekkie>
Yeah, kentonv. I figured they had something like that. But I still don't trust it.
posix4e has left #sandstorm ["WeeChat 0.4.2"]
<ocdtrekkie>
paulproteus That's a fun Twitter, I saw it a bit ago.
<kentonv>
ocdtrekkie: I'm curious to know what kind of scenario you imagine where Google violates their own ToS, opening themselves to lawsuit.
<ocdtrekkie>
kentonv: I'm not an exceptionally trusting person. What outside of Google is capable of assuring me it does what it says?
<ocdtrekkie>
When I tell Google to delete something, what assures me that they did?
<ocdtrekkie>
And would anyone know if they didn't?
<kentonv>
If Google says in a legally-binding context that they will do something, and then violates that, they are putting themselves in quite a bit of risk. Yes, maybe no one will find out, but maybe someone will. There are a lot of employees at Google who would very readily blow the whistle.
<kentonv>
There is actually an internal project called "wipe out" which is basically people who go around to all the other services and verify that they actually delete the things they say they will delete. I interacted with them. They're pretty serious about it.
<kentonv>
and the reason they're serious about it is because they see it as a legal obligation.
<ocdtrekkie>
I mean, in the context that I think Google is openly breaking major laws, and seemingly immune to persecution for it in the US, I'm hesitant to assume that they follow that. Obviously you have personal experience that I don't though.
heliostatic has joined #sandstorm
<kentonv>
hmm, which laws do you believe they are breaking?
<kentonv>
if you mean, say, antitrust, I think that Google very much believes that they are not breaking any such law. You can of course argue that they are delusional, but I do not think they sit there and say "We know we're in violation but let's argue that we're not.". OTOH, blatantly violating their own ToS would be another matter. I think if they intended to data mine their cloud customers, they would say so in the ToS.
<ocdtrekkie>
The OHA is very possibly the most textbook definition of a trust out there. Right next to Steve Jobs personally chatting with five major publishers on setting consistent prices.
<ocdtrekkie>
To me, if they can believe they're not violating those laws, I imagine they can believe they're not violating their ToS even if they are.
<ocdtrekkie>
I have a limited trust in companies based in part, with what I know of them and my history with them. I don't have faith in the CEO of Google. I've been burned more than once by them. So if there isn't an independent party verifying what they say, I'm going to be pretty suspicious.
<ocdtrekkie>
On the other side of things, I place a lot of faith in you and the Sandstorm team on what I know of you guys and how you approach things.
<ocdtrekkie>
Someone made a good point commenting on the note about data if you guys were ever sold, because I obviously may not have the same respect for whoever that might be.
<kentonv>
FWIW, I just tweaked that part to specify that we'll notify user first, similar to Github's ToS (which I found through tosdr.org)
<ocdtrekkie>
I was looking at tosdr. It's neat.
<paulproteus>
I believe jancborchardt was involved in tosdr. Perhaps still is?
<ocdtrekkie>
Once you guys finalize your ToS, you should get it rated. \o/
<kentonv>
I'm not sure I agree with all of the things that tosdr rates thumbs-down
<kentonv>
they give Github a thumbs-down for requiring the user to "defend and indemnify" Github for the user's own illegal actions carried out through Github's service. That seems harsh.
<kentonv>
our policy has a similar clause
<kentonv>
our ToS, rather
<ocdtrekkie>
Well, Github has a B though.
<ocdtrekkie>
Which isn't bad.
<ocdtrekkie>
One would expect you to be like... Willing to fall on your sword for customer secrecy to get an A.
<ocdtrekkie>
"We misplace our logs in dev null as they're generated"?
<ocdtrekkie>
Reading Google's terms now that I'm home.
<kentonv>
hmm, it seems like the argument they are making is that a user doing something illegal on github could be held responsible for *github's* failure to do something about it in a timely fashion (whereas they're responsible for their own failures regardless). This still involves the user having done something illegal, though.
<ocdtrekkie>
"Subject to Section 7.2, Google may discontinue any Services or any portion or feature for any reason at any time without liability to Customer." <- Delightful. Section 7.2 doesn't really hold them to any actual obligation to support deprecated features either.
natea has quit [Quit: natea]
ArcTanSusan has quit [Quit: ArcTanSusan]
ArcTanSusan has joined #sandstorm
joshbuddy has joined #sandstorm
<iangreenleaf>
paulproteus: I'm back to thinking about install.sh for my Ansible playbook.
<iangreenleaf>
Here's my first question: I'm going to eventually want control over all of the config options; Sandcats, port, install dir, etc etc. So should I be doing a "development" install or a "full" install?
<iangreenleaf>
Normally I would assume the full install is when all the knob-twiddling happens, but in this case the development install currently is the more configurable one.
<iangreenleaf>
Is that intended? Should I ignore the name and go with the development install, even assuming this is meant for production situations?
bb010g has joined #sandstorm
<kentonv>
iangreenleaf: Dev installs aren't appropriate for production. It will enable things like debug user accounts which throws security out the window.
<kentonv>
beyond that I'll let paulproteus comment on how best to configure prod installs
<iangreenleaf>
kentonv: K, thanks. That would be my usual assumption.
<iangreenleaf>
In that case I'll assume I want the "full" install and I'll work with paulproteus to make the full install more configurable.
<paulproteus>
I _kind_ of want to say, "If you know what you're doing, you should be able to provide a config file, and that should seed the installer, and if you don't test your config file with a current installer, then you won't be too happy" but maybe I should be nicer than that?
<paulproteus>
I also should go to sleep. iangreenleaf let's find some time tomorrow (Wed) to sync up about this.
<paulproteus>
meonkeys: BTW I almost forgot to say -- the Sandstorm team would be _very_ happy to fact-check any articles you write about it, if you like! I would personally be thrilled to.
<kentonv>
jancborchardt: hey, can you comment on why tosdr dislikes indemnity clauses?
<jancborchardt>
kentonv: phew, good question. Best come in #tosdr and ask there. hugoroyd is our legal expert
<jancborchardt>
kentonv: that said, maybe we also need to adjust, so your input is very welcome :)
<kentonv>
cool, I may drop by some time when I'm not coding. :)
ArcTanSusan has quit [Quit: ArcTanSusan]
mort___ has joined #sandstorm
erikoeurch has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
joshbuddy has joined #sandstorm
jadewang has quit [Remote host closed the connection]
joshbuddy has quit [Quit: joshbuddy]
erikoeurch has quit [Ping timeout: 256 seconds]
erikoeurch has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 244 seconds]
amyers has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 258 seconds]
amyers has quit [Ping timeout: 276 seconds]
mort___ has quit [Quit: Leaving.]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 246 seconds]
natea has joined #sandstorm
natea has quit [Quit: natea]
natea has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 244 seconds]
jadewang has joined #sandstorm
ArcTanSusan has joined #sandstorm
jadewang has quit [Ping timeout: 252 seconds]
<meonkeys>
paulproteus: awesome, thanks
ArcTanSusan has quit [Quit: ArcTanSusan]
erikoeurch has quit [Ping timeout: 244 seconds]
jadewang has joined #sandstorm
joshbuddy has joined #sandstorm
jadewang has quit [Ping timeout: 252 seconds]
<iangreenleaf>
paulproteus: I'll be around on and off the rest of the day, so hit me up when you have a second
<paulproteus>
iangreenleaf: Cool. Now is probably a perfectly reasonable time.
<paulproteus>
I should take a few serious minutes and make sure I understand what you want to do.
<paulproteus>
My concern from my end is that I'm going to make install.sh more complicated with prompts whose interactions contradict each other and have to do a whole lot of user-friendly but hard-on-me checking logic.
<paulproteus>
But I don't know that this is a fear grounded in reality.
<paulproteus>
I get that you will want to customize things. I'm wondering if "edit/create a custom config file" is a better option for you than "provide inputs to install.sh". Curious what you think.
<paulproteus>
For example, if you specify a WILDCARD_HOST that doesn't resolve, should my tooling prevent you from continuing?
<paulproteus>
I could write up better docs about the config options, which _might_ be enough for your needs? But really I'm curious for your input here.
<iangreenleaf>
I'd be totally happy to do it via config file, yes. I figured I'd create the sandstorm.conf file, but atm that only does some of the config.
<paulproteus>
What other config-ing are you interested in?
<iangreenleaf>
My actual requirements are pretty loose. All I need is for users of my playbook to be able to set the various configuration options ahead of time, and then my playbook needs to translate those into something that lets the install run without interaction.
* paulproteus
rereads install.sh
<iangreenleaf>
So I'm basically interested in any config options that a person might reasonably want to change.
<iangreenleaf>
Which is also roughly the set of everything install.sh prompts one about.
<paulproteus>
iangreenleaf: Are you OK with the --unattended-config= option insisting that _all_ the provided parameters be specified?
<paulproteus>
If so, that massively decreases complexity on my end, I believe.
<paulproteus>
Oh, sudo vs. non-sudo
natea has quit [Quit: natea]
<iangreenleaf>
Yeah, fine with that. My workflow really can't handle interactivity, so if any of the missing things is going to cause a prompt it's better to quit early.
<paulproteus>
iangreenleaf: A few more thoughts on the pad; let me knw what you think.
<iangreenleaf>
k, looking now
<paulproteus>
iangreenleaf: OK, I'm pretty happy with this, and I can't think of anything it's missing. Oh, Sandstorm bundle version.
<iangreenleaf>
I'll take a look through install.sh and my notes and see if I see anything else.
<paulproteus>
Great. Then there's the question of when and who will implement this. I'm pretty happy with this as a spec, so if you happen to want to implement it, I'd be very grateful, and give you feedback & do reviews.
<paulproteus>
Otherwise this doesn't seem crazy complicated, so I can probably get to it sometime in the next couple of weeks.
<paulproteus>
I propose that once you're happy with the spec, you file a GitHub issue.
<iangreenleaf>
Sounds good. I'd be happy to do some work on it, but it'd probably be easiest if you at least set up the structure of looking for the unattended config file, since I think you have a clearer vision of where/when/how that happens in the script.
natea has joined #sandstorm
<paulproteus>
Right, fair enough. (-:
<iangreenleaf>
If you do the outline I could work on filling in some of the options.
erikoeurch has joined #sandstorm
<paulproteus>
I'm grateful that you are willing to take the time to have these conversations and think with me about how to make the changes minimally invasive to the existing installer!
<iangreenleaf>
Of course! I'm glad you're so responsive.
<iangreenleaf>
Ok, the only option I found that wasn't on there was START_AT_BOOT
<paulproteus>
Oh, interesting.
<paulproteus>
I imagine that we should always set that to yes, but I guess I can be convinced : P
<iangreenleaf>
My thinking is that people might be using their process manager of choice and want to run Sandstorm via that instead of the system default
<iangreenleaf>
for ex. Monit
<paulproteus>
Oh, interesting.
<iangreenleaf>
so they can just turn off start-at-boot and handle setting up their thing on their own
<paulproteus>
I _guess_ it could be OK to disable that. But I kind of think that's going to be an error-prone mess that no one should sign themselves up for.
<paulproteus>
Having said that, you tell me. (-:
<iangreenleaf>
I mean I don't intend to help them beyond just making it possible. But I imagine it's a desire people will have.
<iangreenleaf>
Once you're bought in on a particular system, it's very beneficial to keep everything under that same system
<paulproteus>
Can I suggest we write in the docs, "If someone wants this, we can implement it?" and then see if anyone actually asks for it?
<iangreenleaf>
sure
<paulproteus>
If you personally want it, I can live with adding it now, but I want to postpone it as long as possible.
<paulproteus>
b
<iangreenleaf>
nope, I don't personally want it, at least right now
jadewang has quit [Remote host closed the connection]
<phildini>
Neat post.
<phildini>
I'm excited to see how Sandstorm actually implements the UX around asking for these things.
<XgF>
kentonv: Your choice of a contact picker is quite possibly the worst example you could have picked...
<XgF>
because the legitimate app *doesn't* need access to your contacts on Android!
<XgF>
You fire off a "Select contact(s)" activity intent and the contacts app lets the user do the picking
jadewang has joined #sandstorm
<kentonv>
XgF: I'm aware that Android actually implements this but my understanding is that almost no app uses it, they all ask for full access and display their own picker
jadewang has quit [Remote host closed the connection]
<XgF>
kentonv: Every app I've encountered which does so does this because they want to steal all my contacts :P
<XgF>
Seriously, apps which do that are being intentionally obtuse because the Android contacts API is an absolute nightmare
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 252 seconds]
jeffmendoza_ has joined #sandstorm
jadewang has joined #sandstorm
bb010g has quit [Quit: Connection closed for inactivity]
<ocdtrekkie>
Great post, Kenton
natea has joined #sandstorm
natea has quit [Client Quit]
<kentonv>
XgF: I've updated the contacts example to discuss Android's contact picker.
<erikoeurch>
great blog post! Quite reassuring to know apps won't be able to make arbitrary network requests without specific permission
<ocdtrekkie>
Can you put them in vagrant-spk somewhere?
<paulproteus>
I guess, it just seems a little sad to leave them hanging around the vagrant-spk repo.
<ocdtrekkie>
Are they large or do they have a lot of files?
<paulproteus>
Then again, maybe they should be versioned with vagrant-spk.
<paulproteus>
Could have, like, vagrant-spk/example-apps/php
<ocdtrekkie>
I feel like vagrant-spk/sample-apps would be a sensible place.
<paulproteus>
vagrant-spk/example-apps;/python
<ocdtrekkie>
Yeah
<paulproteus>
I think I'm+0 on this.
<paulproteus>
zarvox: curious for your take
<ocdtrekkie>
So, will normal spk instructions be retained somewhere?
<ocdtrekkie>
I prefer roughing it with the raw tool.
<paulproteus>
I think so, ocdtrekkie , but I haven't decided on the name for them. Maybe "Documentation for spk tool" or something.
<ocdtrekkie>
I feel like it'd be better to have instructions specific for each tool, and have the packaging guide recommend vagrant, and qualify why you might pick different tools.
<ocdtrekkie>
Or something.
<paulproteus>
zarvox: Also are you still +1 on me making a docs/ directory and making vagrant-spk.readthedocs.org that contains the vagrant-spk docs, which has the upside of letting us keep multiple doc versions online, with the most recent being the default but letting people read old versions?
<paulproteus>
e.g. how Django Docs have a version chooser at the bottom
<ocdtrekkie>
You've got three tools currently, and that's not even covering the likelihood that you or the community may make more as applicable.
<paulproteus>
Other than "old habits die hard", ocdtrekkie , any reason you prefer roughting it with the raw tools?
<paulproteus>
Along those lines, have you tried vagrant-spk yet?
<ocdtrekkie>
Haven't tried it, no.
<paulproteus>
zarvox and I plan to spray parts of meteor-spk into vagrant-spk, fwiw, removing the need for meteor-spk.
<ocdtrekkie>
I generally want to use the thinnest solution that does the job.
<paulproteus>
i,i who are you, kentonv?
<paulproteus>
(but yeah, I can understand that.)
<paulproteus>
The reason I like vagrant-spk is that there's less to explain, I feel, but it is thicker.
<ocdtrekkie>
If I'm going to run a Linux VM anyways, I'd rather use spk, and if porting a Meteor app, meteor-spk.
<ocdtrekkie>
Even if vagrant-spk does the latter, it makes sense to me to keep it.
<paulproteus>
Yeah. I'm not going to destroy it, just de-emphasize it, is my notion for now.
<ocdtrekkie>
I'm not trying to knock vagrant-spk, and for some of the apps I don't know how to port with spk, I should probably try it.
<paulproteus>
I know (-:
<ocdtrekkie>
But I think you guys should embrace the options. And then specifically recommend one for people who are getting started.
<zarvox>
paulproteus: sorry, was having in-person conversation, didn't notice all the highlights <_<
<zarvox>
reading backlog
<ocdtrekkie>
Does the packaging guide make sense as a single monolithic document? Or should it be a bit more broken up for reference purposes and then have kinda a starter guide that steps you through your first package?
<paulproteus>
np re: in person conversation
<paulproteus>
I think the "Packaging Guide" should be a "Tutorial that will definitely work for you, followed by links to relevant tips and other things you could have done instead"
<ocdtrekkie>
What's this "in person conversation"? Do people do that?
<paulproteus>
Since I think such a tutorial is the best material for a first-time docs consumer.
<zarvox>
paulproteus: I'm +0 on this if we have a better way for people to obtain vagrant-spk (which probably means windows support some day oh boy)
<paulproteus>
I'm approximately excited about Windows support.
<ocdtrekkie>
I'm a Windows user. \o/
<paulproteus>
++
<ocdtrekkie>
But I like my raw spk tool, so I'm just difficult, I guess.
<zarvox>
paulproteus: definitely still +1 on you making a docs/ directory and having docs on readthedocs.org
<paulproteus>
Cool.
<paulproteus>
What is "this" in "paulproteus: I'm +0 on this if we have a better way for people to obtain vagrant-spk"
<paulproteus>
zarvox: ^
<zarvox>
+0 on making sample apps in vagrant-spk's repo as subdirs
<paulproteus>
zarvox: Also, crazy idea or not? We can embed a copy of vagrant-spk in .sandstorm/ in the app
<paulproteus>
The main reason it's crazy is that if people try to upstream these directories, they'll be like 'what is this program and what is it doing here'
<zarvox>
crazy idea
<ocdtrekkie>
What's the +0 thing about?
<ocdtrekkie>
Clue me in.
<zarvox>
the +0, +1, -0 are "how I feel about this idea you suggested"
<ocdtrekkie>
That's what I saw about homebrew today.
<ocdtrekkie>
/random
<zarvox>
Yeah, wtf Google :/
<paulproteus>
Meh.
<kentonv>
it's not so much Google as whatever random engineers were assigned to interview the guy
<paulproteus>
I can't get excited about micro-second-guessing people's hiring decisions for candidates I don't know for roles I don't know.
<kentonv>
unfortunately those engineers are given very little guidance on how to evaluate candidates. This is in part because no one knows how to evaluate candidates.
<kentonv>
of course, when someone comes along who invented and implemented a widely-used piece of software, generally you don't need to do much evaluation
<kentonv>
but Google has a process and they'll still send you through the process
<kentonv>
and the individual interviewers will do to you what they do to everyone else
<kentonv>
and the outcome will be fairly random
<paulproteus>
Which seems basically OK to me. I guess I just don't feel entitled to a job anywhere.
<kentonv>
indeed, but it's still fun to point at them and laugh when their complicated expensive process produces an obviously-wrong decision.
<zarvox>
To me, the wtf is not so much the rejection, as the utter mismatch between skills-needed-to-succeed and skills-evaluated-for-in-hiring-process
<zarvox>
I'd have assumed Google, with all its data, would be able to evaluate what things in interviews are actually predictive of future success at the company
<maurer>
zarvox: probably varies highly with position
<kentonv>
zarvox: all of Google's data has been carefully analyzed and the conclusion was that there is absolutely nothing they could ask in an interview that was a meaningful predictor of success.
<kentonv>
the interviews are OK at making sure people who literally can't code don't get hired
<kentonv>
that's about it
<kentonv>
since Google HR has been unable to find anything better to do, they stick with what they know