NGram

I too spin up a new DB for every service that needs one. It makes maintenance less intrusive since I only have to shut down one service at a time to update or do a full file backup and I can safely tweak the DB config to best suit the service without worrying about negatively impacting other services on the same DB. I also like the flexibility to choose the best DB for the service, e.g. I use Postgres for a lot of the services I develop but they do also support MySQL/MariaDB, but I have other services that are more tested on MariaDB.

I’d imagine having one database for everything could eventually cause performance problems across all services if the database gets too big or clunky or queries get too complex, even if just one service is causing the problem.

I also run a lot of physical servers (I have about 10 low power computers I use as servers right now) so having a dedicated DB per service allows me to get better performance since the DB can be on the same machine as the service. Not that they need high performance, but it also helps with the efficiency.

An attacker can still send a compromised payload if there’s no signature verification of the update. It takes a more sophisticated attack (e.g. supply chain attack, hijacking AMD’s update website, etc.) but it has happened before to other companies. If the payload is signed and verified, an attacker would also need to gain access to AMD’s private key to successfully send out a bad update. Assuming reasonable security, getting that private key would be a lot harder to get on top of somehow compromising AMD’s update web service.

Also CRC checks over the internet are sort of silly and redundant since every packet sent would already be subject to a similar CRC check and bad packets would be ignored (dropped and re-requested). It would only prevent corruption on disk or in memory which are a lot less likely than transmission corruption.

that carries part of the machine code used to fabricate its own body.

Seems like just a clickbait headline. It could easily contain all of the gcode for printing the book itself and not the part for printing the letters on the page.

But it might be possible to have gcode that (completely) prints its own gcode. Regular programming languages can do that, there’s a whole fun community around cool puzzles that use that. Obviously, this project does not do that.

Actual link to article: https://www.businessinsider.com/coders-keep-laptops-open-in-public-ai-agent-2026-5
Redirect links are tracking links and should be banned imo.

It’s also worth noting that these do not come with dedicated GPUs. The best you can get is a high-end integrated GPU, which is pretty good these days but definitely not good enough to game well around 4K 120Hz

Maybe you should read the article, because the increase in Linux users correlates with a reduction in Chinese users.

Slop overflow, for when the slop machine can’t lie to you well enough

(Proposed) Direct Energy Converters

There’s also another heat -> electricity conversion method used by nuclear fission reactors, though it could presumably be used for anything in place of a steam turbine: thermocouples. Usually people think of them as electrical sensors for heat, but they can also scale up to produce a lot of electricity from a lot of heat. It’s not very new technology either; Voyager spacecrafts use it in their RTGs. No idea about how that scales though.

The article briefly talks about female drivers too, which is what I talking about.

Women drivers can toggle on a preference to receive trip requests from women riders, giving them even more control over how they earn.

(and the image/gif seems to imply it’ll exclusively accept rides from women riders)

But yes, if gender is self-declared then it’d be pretty easy to abuse by a malicious rider (I assume, without proof, that drivers have to be vetted somehow). If they require a phone number for new rider accounts it shouldn’t be too hard to keep banned malicious users out, though. There are more foolproof ways, but they have other issues (e.g. ID verification is a privacy nightmare and potentially transphobic depending on local government policies).

It’s been a little while since I’ve used any sort of taxi service because the local public transit is pretty good, but I know a lot of the USA isn’t so lucky there either. That’s more of a cultural problem though.

On a semi-related note, it’s quite ironic that Uber made a change for only their home nation on International Women’s Day.

That also only solves half of the problem. Female drivers also want to be safe and doing background checks on everyone who has an Uber account isn’t very practical.

i you hate?

LSAG is a good shout but I’m not sure it’s sufficient. It enables anonymous verification of something against a set of known public keys. But you still need to make sure that set of public keys is coming from real humans. It’s not proof that a user has a property (i.e. being human), it’s just proof they are a user.

But yes this is sort of a digression from the actual main problem. The real anti-bot solution is a mix of methods imo.

Maybe we can agree to disagree because I don’t think a specific demographic is enough to overcome the negative network effect at the start. The problem, imo, is that the attrition rate of dating apps is really high and dating apps are only good if a lot of people are located geographically nearby. You either need broad appeal to avoid running out of people early on or a demographic that is unusually geographically concentrated and usurps the attrition rate (ENM comes to mind for the latter).

Of course, you could always make something for dating without the geo proximity, but I think most people won’t want to use something like that at all.

The beauty of new FOSS projects is that they’re quite often hosted and developed for free, so I don’t think that’s much of a limiting factor as long as the community is there. That’s also why I think it’s important to make it big quickly, because that’s the way to get a big enough community before the creator loses interest.

That’s exactly what Retromeet was trying to do :)

Though I do agree that having a broader scope than just the hot-or-not swipe thing would really help to attract enough people to join. Retromeet doesn’t seem to do that, though I haven’t used it so I could be wrong.

Other apps do have some good anti-bot measures which could be adopted for a FOSS project. The problem with a lot of cryptographic solutions for this is that often cryptography is usually more about proving your identity more than proving something about your identity. Tor is also focused on privacy from middle-men, which doesn’t really make sense for a dating app.

I think the challenge boils down to how to prove you’re human without biometrics or other PII. And I think the sad reality is that you can’t prove it. Though you may be able to prove you have unique PII with some sort of zero-knowledge proof…

Unfortunately I think projects like this have extra challenges over even regular social media platforms. There’s also retromeet which seems even more dead (it may have not even made it to a stable release).

The idea is great but for a dating app to work, it needs to quickly get past two network effects: the global network effect (there must be enough people globally, or in a larger region, to get other people interested in trying out the platform) and the local network effect (there must be enough people to match with in most users’ local areas to keep enough people interested). With corporate backing that’s easy enough to do with a dedicated team to market and develop, but FOSS rarely has that sort of manpower. Slow growth is hard too, since users tend to leave dating apps quite often.

There’s also the funny problem if the dev gets a partner usually the partner doesn’t appreciate them staying on dating apps. Developing a dating app could be even worse for the relationship… actually now that I think of it, maybe I should make start a similar project since I don’t like dating…

The mainstream apps (at least the ones that have been around a while) have bot ratios which are much better. They also have active moderation teams which remove profiles that make it through the automated protections. I’d guess they have ratios closer to 20:1 than 1:20 (people:bots)

I can only guess but I think it’s a combination of a lack of effective anti-bot protections and it being a sort of dead platform (so the only users that remain are largely bots which never leave)

I’ve used it before. The bigger problem for me was the people to bot ratio was worse than 1:20

This reads like LLM slop.

According to technical reports from Phoronix, the milestone was reached by Alyssa Rosenzweig, a key figure in the graphics driver development for the Asahi Linux project.

The linked Phoronix article (published yesterday) credits Michael Reeves, noopwafel, and Shiz and does not mention Alyssa Rosenzweig at all.

The speed at which the M3 was tamed—booting into a KDE Plasma desktop environment so soon after the hardware’s retail release—

The M3 is two generations old at this point…

Booting a kernel is one thing; rendering a fluid graphical user interface is entirely another. The M3 achievement is particularly notable because it involves the GPU, historically the most obfuscated component of any System on Chip (SoC).

Again, the Phoronix article (and its linked Xwitter post) completely contradict this, saying instead the rendering is done with “LLVMpipe CPU-based software acceleration”. The GPU is only involved in so far as is necessary to send data to the display.

This article is misinformation, which is against this community’s rules.