nlightcho

I am building an MIT-licensed compatible alternative to GitHub Actions at github.com/automata-ci/automata. Very early in development but it already runs some of our internal workflows.

Counterparty risk is still a thing. This is the cost of convenience, reminds me of the milkman joke in that South Park episode. Maybe a global SPOF owned by people who do not care is not the way to go.

Make sure you are using the instruction tuned model. The base model will be difficult to prompt.

It works in 8-bit with about 12GB of VRAM usage. Here's sample code:

https://gist.github.com/AlexanderDzhoganov/a1d1ebdb018e2e573...

What about running it as a sidecar in the backend pods?

I agree with your argument on principle but cheating in multiplayer games is a real problem and for now kernel level anti-cheat is pretty much necessary until better methods are developed like server-side ML detection. For what it's worth anti-cheat software is routinely disassembled by cheat developers so at the very least it doesn't do anything obviously malicious and likely doesn't have glaring security issues (any of which would get immediately exploited by said cheat developers).

This is how UWP works and it's a UX disaster.

You should use a CSS reset stylesheet like https://github.com/necolas/normalize.css instead.

The cloud providers have enough resources to provide APIs that are compatible with the popular ones. They won't be selling you Mongo but a Mongo-compatible replacement built in house.

SegWit needs 95% to be activated, it's not even close.

I would say Tor but rumor is the US gov have ways to break it.

Working hours is a pretty arbitrary concept that depends on the business. Every hour is a working hour if you run a 24/7 store.

A really simple templated queue that uses std::mutex.

https://gist.github.com/AlexanderDzhoganov/cffa9aaae5a325cdf...

So this is what Ethereum would look like without blockchain tech.

All Turing complete systems used in practice are distributed at some scale so your argument is non-sense.

This sounds incredibly complicated :) I would definitely use TOR if I believe I'm facing a dedicated and sophisticated threat. For now I have tried to clarify the issues in the FAQ and can only hope that people read it and don't get screwed over by wrong expectations.

These are very good points. I believe that adding any real crypto to the JS code to be a doomed path so I probably won't go for that. My only argument right now is couldn't one verify that the IP of the recipient is the same as the address of the expected receiving device (or router) and be somewhat sure it's not MITM?

Thank you for the feedback! I will change the wording of that FAQ question (+ answer) and make it more detailed.

I'm not sure about how I should go about demonstrating what makes this model more secure, except making it more obvious that it doesn't involve storing your data on servers not under your control which is the case with solutions like email and skype.

I trust my browser's developers with my most sensitive data (online banking password, government id etc.) but that does not mean I believe I am fully secure in doing so. There could always be a bug in the WebRTC implementation or the SSL library or the hardware. Maybe I should rephrase the FAQ to read "Don't put your highly sensitive data on the Internet at all".