I myself was bitten by a radioactive grad student in 2008 that was obsessed with this idea at the time, and have since learned that almost every major household name lab PI has thought about this in one form or another.
Maybe you should check sources that have been around longer than 2017 or even 2008. Optogenetics has been established as a field since at least 2005 (you can also search pubmed for optogenetics 2005). The field had been established and well known among microbiologists for 12 years when you discovered it.
To me this sounds like a computer-generated voice for obvious pro-privacy reasons for this kind of project. If it bothers you, then maybe work on better voice synthesis tech! I assume it sounds not-leading-generation because it was locally rendered but I could be wrong.
Why stop at software? Open-source software is a good idea in election systems. The principle could be better generalized as an "open" (copyleft licensed) process for the entire system, regardless of whether the election system is implemented as software or not.
Anyone who talks about election security should be required to spend at least a few moments walking around Defcon in the election machine hacking village. Even absent electronic voting machines we still need to apply that same level of rigor to security across all domains of the election system no matter what format is used.
More fundamentally, the epistemic meaning of a ballot, a vote, or an option on the ballot, how options are even decided for inclusion or their exclusion, which outcome deciding algorithms are used, and how "the result" is interpreted by society or implemented by a political agent is deeply confused. The vote itself has very little resemblance to what actually happens. Such things likely cannot be formally specified anyway. Massive amounts of ambiguity, noise, error rate, and insecurity are to be expected in these kinds of systems. So what then are we even doing with all this? I am not referring to what we say we are achieving, or what we say we are intending to achieve, but rather what kind of actual outcomes be can supported by careful engineering of all these components?
Note that Asterisk magazine is basically the unofficial magazine for the rationalism community and the author is a rationalist blogger who is naturally very pro-LessWrong. This piece is not anti-Yudkowsky or anti-LessWrong.
Hi, your docs say that users don't need state syncing, but when using Stripe you do need state syncing or to ingest the Stripe events. I also don't see any information in the docs about handling e.g. chargebacks or other events and listening for (or otherwise syncing against the history of) those events. I'm a little confused - why would I want to not have that? I could be misunderstanding this project though!
Ah yes, we're still entirely built on Stripe, so all your chargeback management, tax handling, subscriptions and payments are still handled by them! We are not a Stripe replacement.
When our users integrate Autumn, they don't need to handle the state syncing or any Stripe events, as we do all of that for them.
Eg, one of your users, John, subscribes to a Pro tier. We'll listen to that event from Stripe, and grant them access to the right features (eg premium analytics and 100 messages).
From your app, you just query Autumn to ask "does John have access to send messages?", and Autumn says "yes".
When the John's payment fails, we again handle that event from Stripe. Now when your app asks whether John has messages, Autumn says "no, their payment failed".
When you log into Stripe, you can still see everything as normal, and take actions as you normally would!
Edit: now that I'm writing this comment, I realize that we probably should be listening to the chargeback event so we can block access to features if that happens. We'll definitely handle this case, it's just that no one has needed it so far...
Huh, weird. I don't think I have ever wanted to login to Stripe and take manual actions. Usually I hook up Stripe events to actions in my applications, like "The user subscribed, wire them up to the drip lifecycle" or "The user unsubscribed, remove them from a certain marketing list and try to schedule an exit interview" or other hook-ups.
Ah yes. Interestingly most of our users don't set this up in the early stage. But for the ones that do, they need webhooks for this. We have a single webhook that fires whenever a customer's state is updated (eg subscription started, cancelled, downgraded, expired) etc, that the downstream functions you talk about rely on.
That is awesome. A list of power tools on Amazon went from 2.5MB of HTML to 236KB of markup. That is huge! Wow, thank you for sharing.
This is half the equation. Also, lot of the information in the markup can be used to query elements to interact with because it keeps the link locations which can be used to navigate or select elements. On the other hand, by using the stacking context, it is possible query only elements that are visible which removes all elements that can't be interacted with.
> How do you know it's not selected because it's the one with the most paid ads? Or reddit fake reviews? Or llm generated seo articles about it?
These questions apply to any review or recommendation, from anyone, not just LLMs. How did anyone find out about the product at all? Did they do rigorous testing before they made a recommendation? Is there shared understanding between the recommender and recommendee about desired level of quality or what the user intents that need to be satisfied are? Are they even speaking the same language? Is their concept of "red" the same as ours?
At some point, you have to make a decision and buy with imperfect information, and treat it as an experiment. If it's not right for you, then return it for a full refund from Amazon. This is unfortunate. It costs money, time, and adds lots of friction to the whole process.
Maybe advertisers or manufacturers should post quality assurance bonds for their products, in addition to money-back guarantees or easy returns. Upon receiving a lemon or dumb product, you would return the item and activate the arbitration/bond clause and possibly get money out of the posted quality assurance bond.
> These questions apply to any review or recommendation
Sure but even on HN people seem to treat them as some kind of omniscient Gods or oracle of truth. It's like we all lowered our defences and stopped being critical because the new circus monkey does cool tricks.
At the end of the day they're blackboxes built on stolen data by for profit private organizations, all the red flags are here
You can also directly pull in the emulation state and map back to game source code, and then make a script for tool use (not shown here): https://github.com/pret/pokemon-reverse-engineering-tools/bl... Well I see on your page that you already saw the pret advice about memory extraction, hopefully the link is useful anyway.
reply