rancor

Since this is basically a wrapper around libllama.so, I would assume that the performance is roughly the same as llama.cpp upstream.

The performance will be so-so, but you can buy an Intel Arc B70 for $1000. There are definitely ways to get going for less.

FYI, llama-server can now be run in router mode so llama-swap is probably only needed for more exotic scenarios.

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

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

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.

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.

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.

Good article, but the response to the last question on the use of cannabis in warfare is pretty thoroughly wrong: https://sensiseeds.com/en/blog/cannabis-may-used-weapon-war/

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.

Sorry, I thought it was common knowledge that people associated with her campaign were engaging in this type of activity: http://www.thedailybeast.com/articles/2016/04/21/hillary-pac... .

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.

Very likely the work of Hillary's shill force, pretty low odds they don't follow this site when major news comes out.

So, they'd like me to download a 31MB app with "Precise location", "Read contact data", "Modify or delete USB storage", and "Full network access" (among others!) so I can order tacos? I'll pass, thanks.

Yes, these days I'll make sure that it sees a decent amount of power on time and several full drive writes before ever trusting data to it.

Used in a small file server, my net failure rate on Seagate's consumer 3TB drives has been over 50% thus far. The pair of their SAS drives I currently have in use have been fine, although both of them are still below a year of service life... Edit: Just checked my drive status, and yet another one has dropped. If I'm doing my math correctly, that's 75% of the drives that weren't DOA...

Nope, you're right on the money. My first thought was "this guy needs more VDEVs". Given the hardware and use case, 4x 6 disk RAIDZ2 VDEVs would make a ton more sense, and could also be cross-cabled to allow a controller failure.

The other half of the answer to this problem is to favor small interfaces, ideally a single method. For example, a UserStore interface could be quite large, but if it's composed of UserCreator, UserUpdater, UserFinder, and UserDestroyer subinterfaces, then you can easily arrange to only use the small, task specific, interface.

Agreed that it's all quite a bit more of a pain than using a serious mocking toolkit, though changes in testing practices and API design help substantially.

Thanks for the tip, for some reason it never occurred to me to do this for large interfaces.