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."
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.
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.
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 is a really good concept, definitely going to use it with the kiddo. On a laptop screen, the buttons could be bigger, hard to hit them with little fingers.
The Hue bridge is capable of this type of scheduling without any other devices. Philips simply hasn't included any useful level of flexibility in their app, so the use of All4Hue or other low-level apps is required.
Don't be silly. Real work would mess up the scam, which works roughly like this:
1) Build a software system that appears to perform a real-world function.
2) Offer that real-world function at a loss.
3) Founders and early investors collect sweet, sweet bagholder dollars.
That, of course is a Ponzi scheme, but the S-1 makes it all legal!
OK. Leaving aside that the whole article kind of smells of self-justification over the approach of the LA Times itself to reporting actual news vs. opinion, there's a mathematical issue here. If Deadspin were relatively unpopular with sports fans, their non-sports content would naturally be relatively popular due to it's general audience appeal. And even if this weren't true, most fans care about their particular sport, meaning that the non-sports articles will by the same logic have better viewership even if they are less popular with every given segment of the Deadspin audience. Thus, the content can be "well received" without actually building the site's target audience(s), the targeted audience(s) for which their advertisers pay an (assumed) premium.
I've worked with WebRTC NAT punching pretty extensively, and it is not the solution to your problem. STUN and TURN both require details like proxies with fixed IP addresses, specific DNS and SSL configuration, and so on. So for the nodes to be independent, most users will need to set those services up.
So while the added network layer of Tor (or any overlay network really) certainly adds a level of complexity, from the application standpoint it actually simplifies matters for the following reason: Your application doesn't need any longer to think about the topology of the underlying IP network, as this implicit detail dragged in by direct IP connectivity use is abstracted by the overlay network. Instead, your application is able to interface with any peer via (in the case of Tor) an HTTP proxy and a set of opaque base URLs.
IOW, you're going to need one or more additional daemons to make the P2P part go, and Tor is legitimately the simplest thing available today that accomplishes this without ruling out other styles of overlay network from an architectural point of view.
My favorite NAT-busting mechanism is Tor hidden services, The onion network provides the basic P2P overlay as well, so it keeps life simple. STOMP over WebSockets is cool, and I believe can be implemented without using any Chrome code these days.
In my experience, urxvt is both faster and uses less memory than xterm by a good margin, although there's not such an appreciable difference on a modern system. Gnome Terminal, on the other hand, is beyond slow, far worse than the still slow but acceptable Konsole.
I'd look hard at the logs, it certainly feels suspicious to me, although admittedly I haven't seen any commentator action suggesting anything other than a flagging campaign.