Hacker Newsnew | past | comments | ask | show | jobs | submit | troyjfarrell's commentslogin

Looks like it could be a more batteries-included/opinionated alternative to RxDB (https://rxdb.info). The relational queries might help some people who tend to think in SQL as opposed to documents (as in CouchDB or MongoDB) and the WebSockets for synchronization will help people get started more quickly. (RxDB provides interfaces for those who want to implement their own storage engine and/or synchronization backend.)


Kyrgyzstan passed a law banning many single-use plastics from January 1st, 2027. I hope the ban sticks. It will be challenging to make the economics work.

https://24.kg/english/272281__Production_and_sale_of_plastic...

https://24.kg/english/272323__Kyrgyzstan_to_fine_for_sale_an...


I believe that you can echo the '.dump' command to SQLite.

    echo .dump | sqlite3 db | ssh user@rsync.net "dd of=db_dump"
It worked for me.


You can also pass special commands in the second argument to SQLite:

sqlite3 db .dump | ...


Thanks!

I have added that one-liner to the remote commands page:

https://www.rsync.net/resources/howto/remote_commands.html

... although based on some of your siblings, I changed .dump to .backup ...


Sadly, that doesn't look like it will work. The '.backup' command needs a filename and won't accept '-' or even '/dev/stdout', at least in the version available on Debian it will simply error out with "missing FILENAME argument on .backup".

As noted '.dump' will work in your pipeline, but with the caveats I and others noted elsewhere.


Fixed. Thank you.


You've just described Sandstorm. Sandstorm runs instances (called grains) of applications in a sandbox. The application gets a limited file system and a Cap'n Proto RPC connection to the outside world over a unix socket. Sandstorm runs the HTTPS server, which turns requests into RPC calls. Sandstorm authenticates the users and provides temporary subdomains and frames to sandbox the HTML side of it.

https://sandstorm.io/


OP's comments are all about Sandstorm FYI


I build my apps on Sandstorm[1]_. Sandstorm provides authentication as a part of the platform. For Django applications, I wrote Django Loves Sandstorm[2]_.

If your application fits into Sandstorm's model of grains[3]_, then the security benefits of Sandstorm are many.

.. [1] https://sandstorm.io/ .. [2] https://pypi.org/project/djangolovessandstorm/ .. [3] https://docs.sandstorm.io/en/latest/using/security-practices...


and is there a way to turn this to serverless?


Perhaps more so than one-click services, Sandstorm is a platform for securely hosting web apps. It succeeded in making apps (called grains) easy to use, but not in making them easy to package or develop.

Sandstorm provides security by sandboxing applications and giving them a capability-based API (via Cap'n Proto RPC over a unix socket) for connecting to the outside world and other grains. Grains can also export capabilities, which would allow for the pluggable modules envisioned by kayson. Sadly, few grains do this as of yet. In my limited experience with this part of Sandstorm, the developer experience is still rough around the edges.


Sandstorm uses Vagrant as part of the app packaging (for developers) process. It is _not_ used in everyday use of Sandstorm. Instead, "Sandstorm implements fine-grained containers"[1], not VMs.

1: https://docs.sandstorm.io/en/latest/using/security-practices...


I see. So it’s like Docker, but their own implementation? Can’t wrap my head around it right now.


Sandstorm has a pretty unique sandboxing model, which makes it drastically more secure than Docker in practice, but the tradeoffs in terms of packaging differences can be significant.

One of the biggest things is that Sandstorm prefers to sandbox individual documents versus applications, which mitigates a huge variety of security flaws in apps. In most cases vulnerabilities in apps on Sandstorm are not exploitable when run on Sandstorm.

It also manages most authentication and authorization roles for apps in an integrated way, which requires more integration work than just spinning up a Docker container.

Feel free to hit me up if you want to know more, though it would be a lot of work to make Sandstorm work for your business model at this point. It's cool seeing others in the "make open source web apps user-friendly to run" space though.



Thanks! Will read this later in detail and see if anything can be learnt.

I do want to point out that this is from 2014 and we don't use Docker at PikaPods. We use Red Hat's stack, which integrates better with other Linux tools, like SELinux and Systemd.



Oh man thank you, now I can finally self host this awesome project.


Sandstorm is in need of more coders to help maintain and update apps, but it's not abandoned. I use it, both personally and professionally.

It results in a better experience for end-users because applications are actually sandboxed. This (mercifully) means that any security issues in the out-of-date applications does not become a cause for panic. The downside is that packaging those applications is not trivial.


If you are not too picky about the exact model of replacement component, you can get most components at bicycle shops on the other side of the world. They are quite standardized.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: