Pros: Proper EV motor scream. Cons: 56HP.

Yeah, the unfortunate reality with EVs is power and weight are tightly correlated, since the power output is limited by the batteries, and more battery capacity generally means more power output.

Ah... that could explain the apparent absence of airbags.

haha, however, just because you can't move very fast doesn't mean something else moving fast won't hit you.

It took a fair amount of reading between the lines, but here's what appears to have happened: 1) People and entities with partial control over RubyGems attempted to cancel DHH. 2) In response, elements aligned with DHH kicked the former out of RubyGems. 3) Everyone involved is now attempting to legitimize their motives as "good engineering."

In other words, "When you play the game of thrones, you win or you die."

I think more accurate is this:

One person who was a major funder of RubyCentral pulled funding because they were upset at RubyCentral platforming DHH. Neither that person, nor RubyCentral, had control over or ownership of the RubyGems software at that time, though RubyCentral operated the rubygems.org service, which uses the RubyGems software.

The corporation that is the other major funder of RubyCentral (Shopify) responded to this (taking advantage of the fact that this left them the sole significant funder of RubyCentral whom RubyCentral could not afford to alienate) to direct RubyCentral to, without any plausible claim of right, seize control of the RubyGems software repos, and kick out anyone who wasn’t a full-time RubyCentral employee from them.

It’s not about DHH except that that indirectly provided the opportunity, it’s about Shopify seeking to consolidate control of core Ruby infrastructure.

When I choose to pull funding for an organization that makes decisions I disagree with, I'm exercising my discretion to spend my own money in the ways I see fit.

When you do that, you're cancelling someone. That's the difference.

> One person who was a major funder of RubyCentral pulled funding because they were upset at RubyCentral platforming DHH

Yes. To de-obfuscate, they sent a message that he should be cancelled. It backfired spectacularly, as it rightfully should have. Good.

DHH is on the board of directors at Shopify.

No. DHH is on the board of Shopify.

Thank you, this explains it for me. The situation is still stupid tough...

Yeah, it's a bad scene, the Ruby community isn't nearly big enough to sustain major fractures.

Cancelling DHH would be a stupid kneejerk reaction given how much of a major part of Ruby’s story is thanks to 37 Signals and their community involvement, including but not limited to Rails.

If this is the reason, I am behind this takeover. It’s weeding out bad actors that have a shortsighted mentality.

I do not want RubyGems and Bundler to become yet another pair of ideological playgrounds for people that spend more time protesting unrelated causes than actually _writing and developing software_.

I agree, on the other hand, financially supporting someone that you fundamentally agree with the principles is also not doable.

This is all a callout for people to step in and really help open source and free software before it is too late.

It can be by doing work, participating of the discussions, helping reviewing costs and expenses or even money.

This will certainly trigger the heads of evil dudes in suits and it will become a darker scenario.

Unfortunately, and very unfortunately, the world that Stallman predicted is here and we are late to start pushing back.

We are finding out how capital corrodes ethical conduct

I don't really think this is what happened. Seems pretty straightforward: Shopify wants to decide not just who runs RubyGems.org, but also the RubyGems repos. Separate teams (well, formerly)

> 1) People and entities with partial control over RubyGems attempted to cancel DHH

Ok there it is. That would explain why they’re being so cagey. I thought there had to more to this.

Nah, DHH has too much power and authority to be "cancelled". One person pulled his donations - a very generous continuous gift - because he didn't want to fund Ruby Central if they continued to platform bigotry.

Ruby Central screwed themselves by relying on basically two large donors for their funding, and then offended one of those two donors.

Many people trying to cancel him is still a "cancel campaign" in my book. Just a failed one. IMO, it's pretty similar to the last cancel campaign against DHH & his associates https://news.ycombinator.com/item?id=42593223

This is a hell of a way to find out DHH is on the anti-DEI wagon.

The term "canceled" seriously needs to be retired.

If I understand correctly, Sidekiq's owner pulled his funding from Ruby Central because of his concerns with DHH. That's... one person.

Of course, many dislike DHH's views. Others like him more for his views. He is outspoken about controversial topics. Obviously this garners him fans, and detractors. Using terms like "canceled" is deeply useless at best.

It’s a useful term to describe mob behaviour.

Not only is RabbitMQ durable, it has transactions with rollback. The entire set of problems the author describes are down to Reddit using Rabbit like Redis.

RabbitMQ of 15 years ago did not have those features. I have no idea how reddit uses rabbitMQ now, or if they use it at all.

Wal-Mart's Sceptre brand still sells a wide range of dumb TVs. Not super great performers, but also not expensive by any means.

I bought a Jura full-auto within a couple months of the start of the pandemic. Coworkers did likewise. So it's probably a real phenomena.

I've been using SQL Workbench/J [https://www.sql-workbench.eu/] for quite a while now. Uses JDBC so it'll connect to anything, good SQL formatter, builtin scripting commands, support for XLS import/export, headless mode, and most importantly fast even when loading massive result sets.

I've had my Hue setup change through 4 color schemes based on sunrise/sunset and time of day for a good few years now.

I'm not aware of any automagic way to achieve this result. You'll need to use all4hue, which is basically a wrapper app around the Hue API, to set up rules by hand.

Basically, you'll have a set of rules which update a variable based on the time of day. Then use this variable as a condition in every rule that turns on a light, and have another set of rules triggered by changes to this variable when a light is on. Not complicated, just tedious to program as you'll need 4 rules per light(group) for each of these categories.

But the results work with lights that stay on, lights turned on by dimmers, as well as with motion sensors. And most importantly, the entire thing runs on the bridge so no HomeKit needed. Well worth the effort IMO.

Look into Serve The Home's Project TinyMiniMicro: https://www.servethehome.com/introducing-project-tinyminimic...

If you're not too picky about specs, eBay will give you one of these nodes for around $200, although you might have to supply the NVMe.

Per Wikipedia Mexico, Honduras, and Guatemala also have constitutional protections of varying strength.

They do, but in practice they don't. Many European countries which don't have a right to bear arms still manage to have better gun laws than those three Latin American countries (and I should add, a number of American states).

I have, admittedly old and very vague, memories of people talking about rsync being "hard on networks" or "dealing poorly with congestion." I'd put good odds that this bug is why those statements existed.

This seems to be the opposite. You only see it when transferring titanic amounts of data over a pristine connection. If your network had congestion you wouldn't trigger this bug.

But this also explains a bit why rsync is "hard on networks". Most bulk data transfers end up with breaks in the data that give more breathing room to other protocols. Not rsync, it tries as hard as it can to keep the pipe full 100% of the time, making it hard for other TCP slow starters to get a foothold.

BitTorrent does the same thing and used to be a lot more common, just typically not between hosts close to each other.

TCP-based bittorrent, yes.

The uTP protocol (which has an IETF version called LEDBAT) was specifically designed to be used for background transmission, and it should slow itself down if there are competing TCP flows.

One big fat TCP connection isn't so bad on networks. Especially the default behavior of slowly creeping up in speed until it loses a packet, then dropping back down.

As I understand it significant factor in getting this bug to happen is that you're sending tons of data but in a way that's limited by the source.

rsync is hard on networks???????????

Is there any truth to this? I find it hard to believe -- most of the time rsync is tunneled over ssh which seems well enough abstracted from an optimal traffic generation mechanism that i would seriously doubt it's able to outcompete other programs for network resources in a meaningful way ... perhaps this observation evolved because there are a lot of networks that have traffic shaping rules for ssh? unfortunate effects of traffic shaping rules for ssh + low bandwidth connection + rsyncs happening over ssh + an administrator logged into an ssh port via the low bandwidth link

could maybe produce this observed (but non-sensical?) correlation?

The bug requires transferring over 2GB of data without reading from the socket, so it's unlikely; also, a hang is the opposite of being hard on the network. ;) However the uncommon characteristics of rsync traffic is probably why some congestion control algorithms may not deal well with rsync.