zenhack (u/zenhack) - Readit News

zenhack commented on Sandstorm: Open-source platform for self-hosting web apps sandstorm.io/... · Posted by u/srgpqt

yoz · 3 years ago

Just spent ten minutes delightedly reading your updates on this. It looks fantastic! I'm really excited to watch what happens next, and wish I had time to contribute.

Are there primary areas in which contributions would be most valuable, especially from those without Golang experience/skills?

zenhack · 3 years ago

I suppose that depends on what your skill set is.

At some point the project would greatly benefit from some attention from a UI/UX specialist -- I'm doing my best, but it's not what I'm an expert at. Though right now I'm mostly focused on getting enough stuff to work for it to be of interest, and someone fussing with the UI might just be distracting.

Doing app packaging for Sandstorm might be the most accessible way to help for someone who's not a Go dev -- Tempest will of course benefit from more apps when it's ready to run them, and it'd be a high impact thing for the community right now.

zenhack commented on Sandstorm: Open-source platform for self-hosting web apps sandstorm.io/... · Posted by u/srgpqt

apitman · 3 years ago

Sandstorm was (is?) way ahead of its time. Fortunately a lot of its ideas live on (a la capnproto). My understanding is the achilles heel is the amount of effort required to integrate and update apps, since each app needs to be rather invasively modified to work with the centralized authorization framework. Also the general difficulty of managing a VPS or port forwarding. But once integrated it's really slick and secure.

The overall UX is very similar to my vision of the future of selfhosting. It should be as easy as installing an app on your phone, then going through a quick OAuth2 flow to set up a tunnel on a domain, and you're up and running.

zenhack · 3 years ago

Is! We're not dead yet! (see my other comment https://news.ycombinator.com/item?id=36193093).

I don't think app packaging could be said to be the achilles heel -- how much work it involves depends a lot on the app (some things are very easy, others can be painful), but it is certainly not the case that Sandstorm didn't take off because packaging was too hard.

zenhack commented on Sandstorm: Open-source platform for self-hosting web apps sandstorm.io/... · Posted by u/srgpqt

negative_zero · 3 years ago

Super cool idea but sadly seems to have been slowly dying over the last few years :( (unless something has changed recently?)

zenhack · 3 years ago

The biggest change lately is probably: https://zenhack.net/2023/01/06/introducing-tempest.html

But yeah, Sandstorm has been in a state of "not dead but not moving fast" basically since the company went under; things picked up a bit in 2020, and I got oriented-enough on the codebase during that time to keep it floating along, but, per the post, it's never been easy going.

Anyway, I wish I were answering this question in 6 months time, when I'll be able to show off a variation of Tempest that is relatively usable and can do a few tricks that Sandstorm can't.

zenhack commented on Sandstorm: Open-source platform for self-hosting web apps sandstorm.io/... · Posted by u/srgpqt

evolve2k · 3 years ago

What’s involved to get additional open source “apps” into the store?

I was considering Mattermost over Rocket Chat, but it’s not currently supported/listed.

zenhack · 3 years ago

Have a look at the packaging tutorial: https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tu...

zenhack commented on Goblins: A transactional, distributed actor model environment docs.racket-lang.org/gobl... · Posted by u/snicker7

Jeff_Brown · 5 years ago

Looks fun. How novel is it? Can I do these things already in some other language? (Esp. Haskell or Python -- my favorite language and my work language, respectively.)

zenhack · 5 years ago

The networked actor-model bit & CapTP goes back to E originally[1]. The other contemporary real-world protocol based on this design is capnproto rpc[2], which has implementations in several languages including both Haskell (of which I am the author) and Python.

The ergonomics of the Haskell implementation could use some work IMO, and I've got some ongoing refactoring work on a branch. But it does work, and folks are using it.

[1]: http://erights.org/

[2]: https://capnproto.org/

zenhack commented on Cryptography is not magic loup-vaillant.fr/articles... · Posted by u/loup-vaillant

DarthGhandi · 6 years ago

> As long as you are using C...

These things mentioned are what frustrate me with crypto implementations in pure Rust, the attempts at constant time operations aren't that solid and everyone is going to war with the compiler to simply get basic functionality. Replacing pointer arithmetic where it's needed with array indexing stands out the most but there's other issues.

Honestly think just using C bindings and calling it day is the best way for anything going into production.

zenhack · 6 years ago

> Replacing pointer arithmetic where it's needed with array indexing stands out the most but there's other issues.

What situations do you run into where array indexing is not an acceptable substitute for pointer arithmetic?

zenhack commented on Why GNU grep is fast (2010) lists.freebsd.org/piperma... · Posted by u/letientai299

throwaway_pdp09 · 6 years ago

> But I'm more dubious of the idea that carefully optimising yes was a good use of engineering time.

I literally can make no sense of that. Why do you think widely used pieces of software should not be well made.

zenhack · 6 years ago

There's an opportunity cost. There has to have been a better use of that person's time than taking a tool designed to say yes to repetitive "are you sure?" prompts, and get it to keep up with memory throughput. The throughput of a tool like that does not matter.

zenhack commented on Go command support for embedded static assets (files) go.googlesource.com/propo... · Posted by u/eberkund

euank · 6 years ago

This proposal is more powerful than that one rust macro, but rust's abilities around embedding files are much more powerful than go's approach.

This proposal allows "go build" to embed things in a very specific way, but it's not meant to be extensible.

Rust's 'include_bytes!' macro on the other hand is a macro in the stdlib that can be emulated in an external library. I'm fairly sure every feature of go's embed proposal could be implemented via a rust macro outside the stdlib.

For a specific example, I had a project where I wanted to serve the project's source code as a tarball (to comply with the AGPL license of the project). I was able to write a rust macro that made this as easy as effectively "SOURCE_TARBALL = include_repo!()" [0] to embed the output of 'git archive' in my binary.

Of course, there's a very conscious tradeoff being made here. In rust, "cargo build" allows arbitrary execution of code for any dependency (trivially via build.rs), while in go, "go build" is meant to be a safe operation with minimal extensibility, side effects, or slowdowns.

[0]: https://github.com/euank/include-repo

zenhack · 6 years ago

> Of course, there's a very conscious tradeoff being made here. In rust, "cargo build" allows arbitrary execution of code for any dependency (trivially via build.rs), while in go, "go build" is meant to be a safe operation with minimal extensibility, side effects, or slowdowns.

I've been working off and on on a language that tries to get the best of both worlds to some extent. The whole language is built around making sandboxing code natural and composable. Like Rust, it has a macro system, so lots of compile time logic is possible without adding complexity to the build system, but macros don't have access to anything but the AST you give them, so they are safe to execute. There's a built in embed keyword that works like Rust's include_bytes, which runs before macro expansion, which you can use to feed the contents external files to macros for processing. At some point I'll probably add a variant that lets you pass whole directory trees.

zenhack commented on Who still needs the office? U.S. companies start cutting space reuters.com/article/us-us... · Posted by u/onetimemanytime

PenguinCoder · 6 years ago

Paid salary, work hourly? There's no sense in that for the employee.

Get your work done. That's what Salary used to, and should mean. Takes you 20? Good. Takes you 60? Too bad; get it done.

zenhack · 6 years ago

The trouble is that this assumes pre-determined quantity of work. The reality I've seen most in places is that there's no end of stuff to do. The work is never "done."

What there is instead is an expectation of how much work you're supposed to get done per unit time (albeit calendar time in shops that have things more together). But this is in turn informed by how much time you are expected to devote to work vs other parts of your life.

zenhack commented on Why GNU grep is fast (2010) lists.freebsd.org/piperma... · Posted by u/letientai299

thomaslord · 6 years ago

Personally I think there's a line to be drawn somewhere - I can certainly appreciate focusing on readability, but having certain tools run super fast can be very advantageous on a system level.

Generally I think OS-bundled tools that may be used for stream processing of large amounts of data (like grep) should skew further towards performance, because there are a non-trivial number of people passing gigabytes of data through grep every day and a 10-20% performance improvement there is a significant boon to global productivity.

Tools that solve a very specific problem and do it with a strong expectation of correctness and performance are what makes *nix environments so powerful - not only can you throw together a nifty bash script that duplicates the functionality of a massive cluster operation, the script may actually outperform the cluster because of how performance-focused those tools are!

I see this issue as being a bit similar to high- vs. low-level programming languages. Could we write absolutely everything in JavaScript and probably have a lot of the code be more readable than it'd be in C or Rust? Absolutely. But that doesn't mean it's not worth using C in some cases to make the program perform well on hardware that doesn't have enough firepower to just ignore the overhead, and it doesn't mean it's not worth using Rust in cases where stability is absolutely required.

zenhack · 6 years ago

I think grep is a compelling example of when it makes sense to do the extra work here. But I'm more dubious of the idea that carefully optimising yes was a good use of engineering time.