kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
<isd>
As long as we're talking about biblical documents: I don't think we should treat the roadmap as gospel; maybe worth mining for ideas, but ultimately (1) we're in a very different situtation and (2) it's not like the folks who wrote it in the first place were omnisicient. If you skim the .capnp files in particular you'll find plenty of historical notes about this or that that turned out to be a bad idea -- which is just the
<isd>
nature of building ${new_and_interesting_thing}. Better to apply some brainpower as we mine.
<ocdtrekkie>
That is true/fair.
<isd>
re: seeing grains from other systems on one list, +1
<isd>
Having the various grains folks have created during our discussions spread across 4 different servers has made things organizationally difficult.
<isd>
One of the items in there is a "sandstorm distro"
<isd>
(There being the roadmap)
<isd>
I'm kindof of the opinion that actually doing a fully-custom tailored thing is more of a time sink than makes sense any time in the near future. But a variant on that is just a "full-machine" installer that sets up sandstorm on top of CentOS with some integration so it can manage reboots.
<isd>
That gets us out of the business of managing and packaging the rest of the OS, which I think is something to be avoided.
<isd>
So one example where I like the general end goal but am somewhat critical of the details of the design
<isd>
Probably 8 would be current at least by the time we got around to playing with it. But I mostly just picked ${random_stable_distro}; I could be talked in to something else.
<isd>
Anyway, hopefully wekan would be shielded from this, since it'd still be running in sandstorm
<Guest43589>
I meaaaaan... I would hope strategic considerations would be the primary determinate of such a choice rather than personal preferences.. ;)
<xet7>
Well, Sandstorm and Wekan are both made with Meteor, so most likely Sandstorm would get the same problems Wekan currently has. That's a lot of trouble.
<isd>
Sandstorm self-containerizes, so it's not very affected by the distro it's running on.
<isd>
And I know people are running it on RHEL; that was half the reason for adding the "privileged sandbox" mode, though with newer versions that should become unnecessary
<isd>
(I'd be nervous about it otherwise)
<xet7>
Well, maybe, I'm not so familiar with Sandstorm. I'm just trying to get this Snap stuff working and pulling my hair out.
<isd>
There are a lot of contexts in which I too would run screaming from CentOS.
<xet7>
Well, I used to manage CentOS 6 and 7 servers at work. I don't know why cron did not work properly on those servers.
<isd>
Yeah, I have a fair chunk of experience with RHEL/CentOS too. I wouldn't suggest it for anything where we were interacting with system components in non-trivial ways.
<isd>
I just want something that's going to deal with updates to the kernel and such for us.
<isd>
I do think there's room for discussion here.
<xet7>
Of course :)
<xet7>
I would like that Wekan would work well on CentOS
<xet7>
And Sandstorm too
<isd>
But one of my big worries about something like this is, if $distro screws up and pushes an update that breaks stuff and it requires manual intervention to fix, or god forbid get booting again, we could end up in a situation where we have a bunch of users with hosed OSes who have never seen a shell prompt before.
<isd>
So stability is really really important here.
<xet7>
Well, that's what happened with Wekan Snap update. On Debian and Ubuntu servers update did work fine. On CentOS 7 and RHEL7 Wekan stopped working.
<xet7>
it could be because of different versions of MongoDB required, or libc, or something, I don't know. Snap containers should shield from those, but apparently not.
<xet7>
And trying to figure out how MongoDB 4.x requires including libssl and libcurl someway, getting errors about it missing
<xet7>
and errors about networking
<xet7>
and not being able to connect to MongoDB database
<isd>
Dunno. I'm not very familiar with Snap.
<xet7>
Well, Snap is auto-updating container tech from Canonical. I'm trying to make multi-arch Snap packages. I have spent many hours to even keep it working, like Wekan for Sandstorm too.
<xet7>
Anyway, I'll contrinue trying later. Good night :)
<isd>
Best of luck.
<xet7>
Thanks :)
<isd>
Speaking of RedHat, MongoDB and breakage... I worry about the long term re: mongo, since the company has switched over to a non-foss license. Right now we're just running a fairly old version, and we can do that for at least a while -- it's not like it's exposed to anything where I'd be super worried about security -- but if a FOSS fork doesn't materialize, what do?
<isd>
Switching to any other database would be a project
strugee has joined #sandstorm
<Guest43589>
I created a test OpenCollective collective. It'd be great if I could get a few more people to join me in poking and prodding it. https://opencollective.com/sandstormcommunity
<Guest43589>
I'm really loving the expense tracking tool so far.
<Guest43589>
It's pretty simple to set up different tiers. Each tier has a goal, and they have static or variable amounts set up, and different recurring time horizons.
<Guest43589>
I'm taking screenshots as I'm going along and setting it up.
<Guest43589>
It autodetects dependancies in a repository and matches it against their database of open source projects accepting funds in OpenCollective,
<Guest43589>
This would be a cool thing to have integrated into app stores in general. Give devs the ability to funnel funds from their install base to their dependancies with a single toggle.
frigginglorious has quit [Ping timeout: 258 seconds]
<Guest43589>
Anyways, it'd be great to get two other people to join me so we can explore the differences between Admin and Contributor permission levels.
<isd>
Looks like it's not smart enough to look under `./shell/` in the repo -- it's only detecting deps for meteor-spk
_whitelogger has joined #sandstorm
TC01 has quit [Quit: No Ping reply in 180 seconds.]
TC01 has joined #sandstorm
<crab>
hi
<isd>
Ahoy!
frigginglorious has joined #sandstorm
imdeni has quit [Ping timeout: 268 seconds]
imdeni has joined #sandstorm
ocdtr_web has joined #sandstorm
<ocdtr_web>
isd: While MongoDB's license is not OSI-approved, does it present a concern/problem for Sandstorm, in such that Sandstorm itself is open source.
<ocdtr_web>
The scenario where SSPL would become a problem is presumably if someone offered Sandstorm as a service, and then made proprietary modifications to Sandstorm. And even then, I am not sure I would read that as a problem.
<ocdtr_web>
Offering Sandstorm as a service is not offering MongoDB as a service. Sandstorm doesn't offer MongoDB as a service, I would argue.
<ocdtr_web>
The change from GPL explicitly defines offering a service where the primary value of such is the primary purpose of MongoDB.
<ocdtr_web>
I don't think it's possible for Sandstorm to run afoul of the SSPL, even if offered as a commercial service.
<isd>
ocdtr_web : your assessment makes sense to me. But there OSI rejecting it is enough of a red flag that I'm going to ask around a bit to try to better understand the objection.
<ocdtr_web>
isd: It's so claimed that MongoDB withdrew SSPL's application for approval, such that the OSI may have never formally rejected it? I feel like it meets the open source definition, at least far better than licenses which prohibit commercial use.
<ocdtr_web>
Hopefully at some point the open source community will come to some sort of consensus on acceptability of licenses meant to protect business interests of open source companies.
<ocdtr_web>
But given that we still get into fights on whether the GPL is good or not, I suppose consensus doesn't seem likely any time soon. :P
<isd>
Looks like the FSF hasn't actually weighed in yet either.
<ocdtr_web>
So I've begun some issue cleanup. I haven't looked at the "self-hosting help" issues as much yet, but been trying to tag feature requests and bug reports a bit. And closing solved problems or issues not even pertaining to Sandstorm.
<ocdtr_web>
I created a new label, "app-platform" to tag any issue with how Sandstorm interacts with apps, and revived the "shell" label to tag issues likely to be handled solely within the Meteor front-end code.
<ocdtr_web>
This means folks versed in Meteor such as xet7 can look at the shell tagged issues easily, and isd can quickly find all the issues likely to involve the Powerbox, app sandboxing, etc.
abliss has joined #sandstorm
<DanC>
583 open issues. hm. triaging all those would be a lot of work.
<ocdtr_web>
DanC: Indeed! Many are obsolete though. I think I closed out like ten?
<DanC>
closing as obsolete is a form of triage
<ocdtr_web>
It will be a gradual process to make sure everything remaining is relevant and tagged appropriately. But at least the process has started. :)
<DanC>
did you recently get authorization to update issues?
<ocdtr_web>
I did!
<ocdtr_web>
There was an issue someone had about the formatting of their subreddit's theme that truly grated my nerves because it was entirely unrelated to Sandstorm, and the random drive-by which opened it never returned to close it. Was the first one I hit.
<DanC>
"we will eventually support OAuth to third-party servers. " <- references to plans such as that should always reference an issue
<ocdtr_web>
#2925 would probably be the relevant issue/topic to discuss that right now.
<DanC>
gak... 2433 refers to design notes in oasis. They seem to be available just now, but I wonder if they'll go poof soon.
<ocdtr_web>
Likely. It may be worthwhile to mirror that document elsewhere and link it there as a backup.
abliss has quit [Ping timeout: 258 seconds]
<DanC>
"cannot tweet from grains" is not where I would look for OAuth-powerbox design discussions. If 2925 is where the OAuth-powerbox design belongs, please change the title
abliss has joined #sandstorm
<ocdtr_web>
I haven't been renaming any issue titles yet, though I probably will at some juncture to align with whatever we figure out as the short-term roadmap.
<ocdtr_web>
As whatever roadmap we assemble, wherever we assemble it, should be backed by GitHub issues.
<DanC>
ugh... looking over https://github.com/sandstorm-io/sandstorm/pull/2027 ... lots of stuff I don't understand. "Grain makes postMessage powerbox request on Alice's session, gets back a requestToken that has introducerIdentity set to Alice's identity ID." What's an identity ID? My spidey-sense goes off whenever I see stuff like identity ID. looks like NBAC rather than ZBAC (ocap) to me.
ocdtr_web has quit [Remote host closed the connection]