Anticlockwise

This site has developed a lot of content without seeming to directly address the major concerns anyone coming from git flow will have. For example, their code review page does not really address how github and gitlab are both set up to support branch based review, and trunk based review is a lot harder when using those tools. Similarly, I poked around and figured out what they recommend for hotfixes, which is just fix it on trunk and cherry-pick the commit. That works sometimes, but anywhere with infrequent releases (like regulated environments or shipped software) may find that pretty painful. I suspect I could raise more issues if I put more energy into it, but it's hard to want to, given how the content is presented.

Overall, this site reads like someone who's so convinced they're right that they don't bother to take other viewpoints seriously enough to actually refute them.

This is exciting. Seems like searching for scientific papers would be a good long context task.

What are you switching to?

What's your point? I think you're trying to argue that we tax the wealthy as much as the middle class, but this claim doesn't support that. The 10th percentile of earnings in the US is 190k. The 5th is 290k. The 10-5th percentile is reasonable to class as "upper middle class" in many high cost locales.

5th percentile plus might be a reasonable proxy for wealthy, but even if they pay half of income tax receipts, that's not proof that we tax their income as much as we tax the middle class's. Income for the top 5% is on a power law curve. The top 1% starts at 850k - if they contribute twice as much as someone at the top 5, (290k), their percent is still lower.

Meanwhile, capital gains are taxed lower than ordinary income, and the wealthy make most of their income from capital gains. And the most exotic loopholes for reducing taxes on wealth are most available for the ultra wealthy.

If someone earning 5m/year pays 1m/year in tax, they should fire their accountant. And also they're paying less in tax than most upper middle class folks by percentage.

Funding a ubi wouldn't be that hard if we only cared about the kinds of things that get cheaper with time. Right now our federal tax rate is enough to cover 10k/year/pp (though nothing else), but if actually taxed the wealthy as much as we tax the middle class (for example, if we had a higher capital gains tax on public share sales, reducing the amount earned by the class of people who produce no real value and just earn money from stock growth), we could bring in enough to give out 5k/year/pp pretty easily. If everything that matters in life were getting cheaper the way computers and food did over the last half century, 5k/year/pp would be a good start, and as we got richer we could afford more.

But some sectors of the economy get more expensive with time, and those are what are killing us now and what prevents the UBI from being a good idea (before we fix them). Housing, Healthcare, education and childcare absorb more money every year and faster than the economy grows. Give people more money and those sectors just find ways to charge more. If we can't fix the way they do that, we get poorer in reality no matter how much more money we earn.

I realize this isn't how a lot of folks view things. To see it through my lens, imagine for a moment how wealthy we'd be if housing cost less than it did fifty years ago. If healthcare did. If education did. That's the world Keynes imagined, where we could be working 15 hour weeks (probably actually 25 hour weeks, but still) and still feel rich.

I cannot imagine advocating for using shapes as they currently exist for an access control use case. Shapes may limit what the user can see in the app, but I've now put all of my other users data on this user's device! No way can I pass a security audit with that.

I looked at these two systems recently and noted another crucial difference for anyone using them for a use case that included access control. ElectricSQL doesn't seem to (yet) support table joins in a way that would support standard web app access control design patterns. If you're replicating a table to a device, you're replicating the entire table, not a user-limited selection.

Supporting joins is in development, but I'm not yet clear on whether the current dev branch on it goes far enough to support access control use cases.

There's a hack in place that's supposed to help - you can define an electric_user_id on the table - but that isn't actually usable in the majority of use cases, because most ACL cases include records where multiple users can access it. I did explore using views, but electricsql doesn't currently support postgres views.

(if I'm wrong or missed something in electricsql, I'd love to be corrected, as it looks like an exciting project otherwise)

I think calling this reprehensible is a bit over judgemental. Melatonin is pretty safe.

For example, there's melatonin in both human and cow milk (more in evening milk, because infants don't have a day night cycle yet, and giving rise to the belief that smells like an urban legend that the old timey advice to drink warm milk if you can't sleep originally came from drinking night time milk fresh from the cow for the melatonin).

Also, you know what causes us to make less melatonin? Light. Blue light especially. Is it equally reprehensible to allow children to exist in houses with led light bulbs, which affects their bodies just as much as a pill?

It seems likely to me that the addition of a small amount of melatonin to replace that lost due to nighttime lights is a reasonable parenting decision. Of course there's uncertainty, but there's uncertainty about everything, can we please stop freaking out as much as we do, as easily as we do?

Huh. I thought I remembered that they had, and I thought the link agreed with me, but rereading it sounds like they just put a nuclear reactor on a plane and flew it to see if it would kill the crew.

"Between May and August 1961, the Tu-95LAL completed 34 research flights. Much of them made with the reactor shut down. The main purpose of the flight phase was examining the effectiveness of the radiation shielding which was one of the main concerns for the engineers. The massive amount of liquid sodium, beryllium oxide, cadmium, paraffin wax and steel plates; were the sole source of protection for the crew against the deadly radiation emerging from the core."

If you're going to make this argument, I really wish you'd make it more explicit. I think what you're suggesting makes cities unlivable. The homeless drug users have to exist in space somewhere. What do you propose to do with these people? There's nowhere to ship them to that's not owned by someone who objects to their presence.

I understand this feeling, and feel it frequently with other comments, but don't see the comment you're replying to as the best example of that. Their list of reasons are mostly not overcomable with "great engineering achievement" - they're mostly economics. If you don't see a path to overcoming the economics, then you can engineer all you want and it won't succeed in our society.

So maybe a better contribution would be to ask what would drive successful economics of battery swapping? It seems like one critical piece which could happen on its own and would then potentially enable battery swapping is battery standardization. Yes, standardization reduces engineering options, as the parent suggests, but it also makes consumer lives much much better. I've got some non-standard batteries on my ebike and it probably puts a much shorter time limit on the bike's life than I'd prefer.

Standardization doesn't have to reduce engineering options as much if there are a handful of form factors. That's what we've seen with AA, AAA, 9V,etc. We should be aiming for a small set of form factors and connectors that enable sufficient engineering options.

Isn't this only true if OpenAI decides to let you into the gpt4 API? Is there a trick for getting them to turn it on? I haven't heard back from them for access yet.

If a chess engine was programmed with a general goal of winning the game, inadequate rules preventing it from cheating, and sufficient ability to influence the world to do so, it would presumably cheat to win.

If the only path it saw to cheat to win was to kill you and move your pieces for you, there's nothing stopping it from doing so.

Will it kill you because it wants to kill you? No. Might it kill you because killing you is a possible option and that option comes out as a likely way for it to achieve what it wants? Absolutely.

Probabilities matter. Is killing you the best way to win at chess? I have no idea, it depends on too many variables. But it's certainly less likely than if it were programmed to kill you as its goal.

However, as its power to affect the world goes up, it becomes more and more capable of performing actions which accidentally kill you while it pursues an endgame (pardon the pun). Like flooding the town you live in so you can't move, or whatever.

Do you really not understand that software influences people's expectations of what's normal? You're normalizing the idea that everyone should be always available by conflating "attendance in the app" with "working"