<isd>
hypothesis: it should work with files < 1M (iirc, that's the line where sandstorm decides to do streaming vs. just passing the bytes)
<DanC>
falsified by bob.zip and #3
<isd>
Yep, that's way smaller
<isd>
I will investigate
AZero_ has joined #sandstorm
AZero has quit [Ping timeout: 240 seconds]
AZero_ is now known as AZero
* DanC
fleshed out #3
<DanC>
does the FS schema support attenuation? i.e. given a read/write grain, get a read-only grain. Or a grain for a subdir
* DanC
looks...
<isd>
The schema does what you want with subdirs, but doesn't expose a direct way to remove write permissions from a cap.
<isd>
That would be a reasonable thing to add.
<DanC>
yeah; the Emily and E filesystems work that way.
<DanC>
and any of the objects in the schema can be a grain?
<isd>
So, grains are somewhat orthoginal
<isd>
When you do a powerbox request from the viewer grain, it asks for a capability matching the Directory interface. sandstorm presents you with a list of grains that say they can fulfill that request. You click on one, and it can display a UI to let you choose what cap to supply. The demo app doesn't do this, it just always gives you the root, but it doesn't have to.
<isd>
I basically did it that way because I was doing something quick and dirty and didn't feel like building a UI for you to select a directory.
<DanC>
sure
<DanC>
I don't mind building the parts I need
<isd>
But the point of the repo was very much the schema.
<DanC>
the demo app is just the right size, for me.
<DanC>
it brings the schema to life
<isd>
Yeah, that was the idea.
<DanC>
have you built any other sandstorm stuff?
<isd>
A few things. go.sandstorm is general helper libraries for writing apps in Go.
<isd>
I've got a port of znc that is currently not working for me
<isd>
which is not yet on the app market, as I feel it's slightly too janky, but it's good for my own purposes, and at some point I may touch it up and publish it.
jemc has joined #sandstorm
* DanC
kicks the tires..
<DanC>
I forget... is oasis limited to stuff on the app market? or can I upload apps?
<isd>
iirc you need a paid account to upload stuff, but you can do it.
* DanC
finds the Upload app... button
<isd>
(It's possible I'm completely mis-remebering needing a paid account)
<DanC>
well, I have a paid account from the kickstarter days
<isd>
there you go.
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
digitalcircuit has joined #sandstorm
isd has quit [Quit: Leaving.]
isd has joined #sandstorm
<isd>
My local dev setup seems to be broken.
<isd>
something about a fuse IO error. I will have to troubleshoot later.
<isd>
(DanC: this is what has been holding me up re #3)
<DanC>
fuse IO error... I ran into something like that...
<isd>
Hm, I'm on arch though. Will have to see if they've mucked with the kernel too, though I'm doubtful
<isd>
Right now I've just fallen back to using vagrant-spk
<kentonv>
drphish, Sandstorm updates use install.sandstorm.io (to check for latest version) and dl.sandstorm.io (to download update tarballs). App installation and updates use app-index.sandstorm.io.
<kentonv>
The associated IP addresses should be relatively stable but of course I can't guarantee they'll never change.
<kentonv>
we use Cloudflare and Google Compute Engine as infrastructure. (Not app engine.)
<kentonv>
drphish, when writing the offline docs I was thinking of people who want to run a totally airgapped instance, didn't consider people who want to write strict firewall rules but are willing to allow some connectivity. I'd be happy to accept a PR updating the doc to be more useful for your case.
<isd>
Looks like that patch has been upstreamed; not just an ubuntu problem anymore.
<kentonv>
urgh
<kentonv>
I thought Linus doesn't accept things that break userspace. :(
<isd>
Which probably means he'll be amenable to reverting it.
<kentonv>
if someone could tell me where to file a bug report, I'm happy to file it and explain what we're doing
<kentonv>
I think simply removing the "return -EIO" lines (and preceding if()s) would fix the problem
<isd>
Check the MAINTAINERS file?
<kentonv>
I'll e-mail the signed-off-by people
<isd>
There's an entry in MAINTAINERS for both a fuse maintainer and the linux-fsdevel mailing list.
<isd>
Looks like the second signed-off-by is the fuse maintainer
<kentonv>
sent an e-mail
<kentonv>
cc'd you
<kentonv>
in other news, I'm working on murdering proxy.js, one of the oldest files in the Sandstorm source code.
<kentonv>
now that KJ has an HTTP library, it makes sense to move a lot of this logic to C++. It'll be way more efficient, maybe even largely fixing the memory leak issues we have in the frontend today.
<kentonv>
IRONY ALERT: Our memory leak issues are in the garbage-collected code, and I'm trying to fix it by moving logic into non-garbage-collected code.
ogres has quit [Quit: Connection closed for inactivity]
isd has quit [Quit: Leaving.]
harish has quit [Ping timeout: 240 seconds]
harish has joined #sandstorm
<drphish>
@kentonv thanks for the info. Are the IPs that back those DNS entries static?cmd
<drphish>
they appear to be in a pool of 2 ipv4 and 2 ipv6 addresses
<drphish>
(for dl and app-index)
<drphish>
do they vary over time or geographical region?
jemc has quit [Ping timeout: 248 seconds]
pie__ has quit [Ping timeout: 240 seconds]
pie_ has joined #sandstorm
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined #sandstorm
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #sandstorm
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined #sandstorm
pie__ has joined #sandstorm
pie_ has quit [Remote host closed the connection]
_whitelogger has joined #sandstorm
pie__ has quit [Read error: Connection reset by peer]
pie_ has joined #sandstorm
pie_ has quit [Remote host closed the connection]
pie_ has joined #sandstorm
<TimMc>
drphish: Cloudflare probably varies by geo -- I don't know if they do edge caching, but I would assume so, and that would involve DNS geosteering.
<TimMc>
You can get the full list of Cloudflare IP ranges from AWS, by the way.
<taktoa>
I may have just signed up for a sandstorm basic subscription with the ulterior motive of supporting capnproto development :^)
<taktoa>
"hmm, what if I forget about this and it charges me $9/month forever... I guess the sandstorm guys deserve that though"
<TimMc>
:-)
<taktoa>
by the way, are there any plans to support packaging sandstorm apps using Nix? it seems like a match made in heaven...
<taktoa>
(also, fwiw, the Nix store can almost be thought of as a capability-safe filesystem, where "capability" = nix derivation or store path, though you'd have to chmod -r /nix/store for this to matter in practice)
jemc has quit [Quit: WeeChat 1.4]
jemc has joined #sandstorm
ogres has joined #sandstorm
ill_logic has joined #sandstorm
<maurer>
taktoa: A number of people have done partial work on it, myself included. I don't think anyone finished
<taktoa>
maurer: hmm, okay
pie_ has joined #sandstorm
<maurer>
It's not impossible - the main problem is getting sandstorm itself to build cleanly under nix
<maurer>
taktoa: Basically, summary of stuff you'll have to figure out:
<maurer>
1.) How do you get sandstorm to use an installed copy of meteor, rather than one living in your homedir
<maurer>
2.) How do you convince ekam to use installed copies of other dependencies?
<maurer>
3.) Find all the places that the spk tool embeds dates etc
<maurer>
and it should be good to go at that point
<maurer>
I'm trying to find my partial work, it probably works even less well now, but it might at least point out a couple tricks to help you
<taktoa>
maurer: thanks!
<taktoa>
jeez, ekam does not strike me as a very good way to write a build system (and I would consider myself fairly well informed on the subject)
<maurer>
taktoa: ekam does have some good points - its continuous mode is better than most other systems I've seen, and the extensibility mechanism is well suited to vendoring
<taktoa>
interesting...
<maurer>
As a maintainerish/oldschool person though, I am generally put off by vendoring
<maurer>
and since I was mostly trying to package sandstorm, not develop it, the continuous mode did not help as much
<maurer>
taktoa: So, as of the last time I tested this nix expression, it could build the spk tool, but could not build the sandstorm service
<maurer>
but that was a much older (year+) version of sandstorm, so no promises on it doing anything now
<taktoa>
gotcha
<maurer>
Since then, someone managed to package meteor (at least in theory - it's in nixpkgs now) which might help a bit
<isd>
Yeah, as someone who has done a fair bit of packaging, I find ekam frustrating from that perspective. I get the desire to have something that it is smart enough to just figure it out when you put some c/c++ files in a directory, but it seems like in practice every ekam project (all 2 or 3 of them)? has a bunch of custom logic anyway.
<isd>
Also, my experience with build tools suggests to me that you can't bolt them on after the fact -- c & c++ are basically doomed to always have this problem.
<isd>
I've *never* seen a good one.
<maurer>
bazel.build seems promising
<maurer>
I've not actually used it for my own projects though, so I can't give a thorough judgement
<isd>
The only things I've seen that are pleasant to use are language-specific, and they heavily exploit knowledge of the language
<isd>
I might consider it if I were doing something that already depended on the jvm. But for most of my projects, having java as a build dependency feels like mega overkill
<isd>
(bazel that is)
<maurer>
build-dep on a jvm doesn't seem so bad
<maurer>
Most dev machines have one, and it's not like it adds a runtime dep
<isd>
Maybe I'm just still shell-shocked from trying to get java to run on FreeBSD like 5+ years ago.
<isd>
(It's probably easier now)
<isd>
probably longer than that actually...
<isd>
It also just doesn't seem like it's addressing the problems I actually have with build systems.
<taktoa>
isd: once we have "recursive Nix" (the ability to run `nix-build` inside a nix build sandbox), Nix will be a pretty usable replacement for Bazel
<isd>
Like, most systems, everything is great until I add something to the project that does something other than compiling $my-language's source format to $my-language's object format. Then I discover that the designers either ignored this problem entirely, or tried to handle every possible such thing themselves (oh look, they have yacc support... that doesn't help) or invented their own (bad) programming language.
<isd>
taktoa: yeah, that strikes me as a better approach
<taktoa>
I just spent my internship last summer working on getting Haskell packages to build incrementally via Nix
<taktoa>
(my approach was different from recursive Nix, and involved getting the build system to dump the build graph as a .nix file, which could then be used during Nix evaluation, but that turned out to be brittle and difficult)
<isd>
re: building sandstorm apps with nix: you could just have folks install sandstorm itself outside of nix. You don't actually need it as a build dependency, just to run the apps.
<taktoa>
yeah, although that is interesting to me, I was originally talking about having sandstorm itself work through nix in a supported way
<taktoa>
like if a sandstorm app could just be a nixos module or something like that
<taktoa>
the current workflow with vagrant and virtualbox seems painful in comparison
<isd>
I think you could build something that just takes the nix closure and shoves it in an spk, then hands it off to sandstorm.
<taktoa>
yeah, that seems doable
<isd>
But yeah, having vagrant/vbox in there is a bit annoying. You can just install sandstorm locally and call spk directly though, which is what I (usually) tend to do
<taktoa>
maurer: BTW, idk if you are aware, but bazel's internal view of the world is basically the same as nix
<maurer>
taktoa: that's part of what's interesting - it's done at a finer grained level though, which makes it potentially more powerful imo
<isd>
vagrant-spk is just a wrapper that launches a vm and does that for you. It's useful if you're on a system that can't actually run sandstorm
* isd
is using vagrant-spk right now because Arch is affected
<taktoa>
maurer: yes, but that's only because we don't have recursive Nix yet; with recursive Nix we could replace gcc with nix-build and automagically get incremental builds. we won't be able to get the full build graph statically without forcing upstream to use nix though (that's basically the solution bazel uses)
<isd>
Well, not *gcc*; it's not a C compiler. But make, yeah.
<taktoa>
no, gcc
<taktoa>
each gcc invocation gets cached in the nix store
<taktoa>
it's like ccache
<isd>
ah, I see what you mean.
<taktoa>
the approach you just mentioned is what I tried last summer, and it's really difficult to get right
<maurer>
taktoa: The other issue is that the nix-store is not efficient enough for that type of usage
<taktoa>
I think you'd be surprised
jemc has quit [Ping timeout: 248 seconds]
<taktoa>
we have a pretty big builds where I worked last summer (>100 nodes in build graph), and it wasn't a big deal
<maurer>
taktoa: So, the build would be fine - it's just a couple extra directory traversals per open(), which is not super expensive
<maurer>
taktoa: It's the GCs that would burn you
<taktoa>
maurer: shlevy (author of the now-bitrotten recursive nix patch) thinks that there should be "private" nix stores to improve the performance though
<taktoa>
basically like arena allocation
<isd>
related: cabal's new-build is amazing. and it kinda cements my feelings about language aware build tools
<taktoa>
yeah, I really like new-build
<maurer>
I think that while language-knowledgeable tools are important, they tend to fall down pretty hard as soon as you leave their magic world
<maurer>
(try for example, trying to bind haskell code to ocaml code)
<isd>
Yeah. but they basically just devolve into the hell that is everything else.
<isd>
The difference is they're actually good at *something*
<isd>
...I may be somewhat bitter about the state of build systems.
<taktoa>
the ideal scenario IMO would be to just get everyone to adopt Nix or something equivalent (Bazel, Buck, whatever)
<taktoa>
there's no reason we shouldn't be able to write all the build logic in the same turing complete pure language
jemc has joined #sandstorm
<taktoa>
like if I had my way cabal would just be a big nix expression that does constraint solving on a package set including all versions of every hackage package, given a .cabal file
<taktoa>
(yes, I know that that would be hilariously slow in the current implementation of Nix; I think there is a lot of room for improvement there though :^))
<isd>
Yeah, but there are some social problems there.
<taktoa>
oh, absolutely
<taktoa>
the fastest way I could imagine that world becoming real would be if someone high up at apple decided to turn darwin into a nix-based distro
<taktoa>
but sadly that seems very unlikely
<isd>
One thing I think ekam does as well as anything is dealing with custom rules. This is where a lot of build systems fall over.
<taktoa>
yeah, the idea of using regular expressions to compute the build graph is pretty cute
rolig has quit [Ping timeout: 240 seconds]
<TimMc>
Reading up on vagrant-spk... it seems super weird. "Sandstorm makes it easy to keep things small by employing a trick: it watches your server running on your development machine and pulls in all the files the server uses."
rolig has joined #sandstorm
<TimMc>
I'm not sure why I have such an "ick" response to that.
tobald has joined #sandstorm
<TimMc>
Doesn't that make trouble for reproducible builds?
<isd>
Yes, yes it does
<isd>
It really doesn't scale well at all.
<isd>
Most of my apps have been basically one statically linked executable and some templates though, so it hasn't bitten me too hard.
<isd>
...except that time I forgot to include the root ca certs.
<TimMc>
:-X
<isd>
That was fun.
<isd>
But for things like python apps, where you actually have a large number of files that need to be included, it saves a *ton* of space vs. relying on package file lists
<isd>
lots of stuff gets included that doesn't need to otherwise
<TimMc>
hmm
<isd>
and with a language where you've got individual output files for each module in your transitive dependency tree, it gets a little painful to do manually.
<isd>
Ideally, you'd have something like nix with appropriately slim packages.
<TimMc>
When the docs talk about testing out the various features of the app so that all necessary files are marked as needed, would that be covered by the automated API and browser tests that one would hope an app is developed with?
<isd>
hopefully.
<sknebel>
theoretically.
<sknebel>
now I wonder what weird conditional imports and stuff like that are hidden in various python libs etc
<isd>
but it would be nice if that wasn't something I had to write tests for. Basic build-system-working stuff is... basic.
<simpson>
isd: At some point, just using Nix becomes the easiest path.
<isd>
Yeah.
* simpson
uses nix-shell for development environments
<isd>
I think the sandstorm dev stuff generally tries to be a bit too clever with autodetecting things.
<TimMc>
I can imagine having to include a bit in your launcher that goes out and "reads" all the files it knows it will need... -.-
<isd>
TimMc: you can also just put stuff in sandstorm-files.list manually; it won't remove things.
<isd>
and there's alwaysInclude in the pkgdef.
<isd>
When the autodetection stops scaling well you can just stop using it.
<TimMc>
I can also imagine it failing the other direction -- some component does a directory scan at startup, and all that crap gets included.
<TimMc>
It also feels like there has to be a security risk in here somewhere, but I can't see one.
<isd>
I think investing in getting stuff to work with nix, as well as slimming down nix packages as needed, is a useful thing to be doing.
<isd>
The current situation is not great, and I mostly deal with it by having like 1-6 files in my spk in the first place.
Telesight has joined #sandstorm
xet7 has quit [Ping timeout: 240 seconds]
xet7 has joined #sandstorm
tobald has quit [Quit: Ex-Chat]
xet7 has quit [Ping timeout: 248 seconds]
AZero has quit [Ping timeout: 248 seconds]
ogres has quit [Quit: Connection closed for inactivity]
xet7 has joined #sandstorm
ogres has joined #sandstorm
xet7 has quit [Ping timeout: 240 seconds]
xet7 has joined #sandstorm
zopsi has quit [Remote host closed the connection]
zopsi has joined #sandstorm
xet7 has quit [Ping timeout: 240 seconds]
xet7 has joined #sandstorm
isd has quit [Quit: Leaving.]
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #sandstorm
jemc has quit [Read error: Connection reset by peer]
jemc has joined #sandstorm
Telesight has quit [Remote host closed the connection]
ogres has quit [Quit: Connection closed for inactivity]