Which particular LLM was that?

If I'm already using Poetry and not facing any issues with it, is there any advantage to using uv?

Speed. It's an order of magnitude faster, at least.

I actually like this and don't want them to be joined up.

> Wall: Players group 16 elements into four categories (similar to the NYT Connections game)

I have to be the designated pedant here and point out that Only Connect was first.

And unless they've improved it, NY Connections doesn't have nearly enough red-herrings to be interesting.

The difficulty with the Only Connect wall is that you can have 5 sets of 5 or more in each, and sometimes can have loads that could fit a category, e.g. you might have 7 or 8 Pixar Movies listed.

You know that's going to be a category, but you also know it's a waste of time to try them before finding other categories.

There's also linguistic and add/drop letter ones, so if you see "Soul", that might actually be "Capitols missing a letter", "Stars with an extra letter", or "Homophones of Fish".

But it might be straight, so could fit "Davids", "Pixar Movies", etc.

There is a meta-pattern, you typically only have one such missing/add letter group on a wall, and you typically have one "Names" (often common firstname) set. Places in general also feature very regularly, especially with missing parts.

Fully solving most walls in the time limit is extremely challenging. It's slightly easier for the home viewer on the second wall, because there are often common themes across the two walls, but of course the competitors don't get that help.

NYT Connections definitely has less red herrings than Only Connect's wall (and doesn't have the pressure of the timer, either...), but the quality has gone up significantly in the past year and half.

If anyone wants to try, I actually built a command line player of the NYT Connections game here: https://github.com/jleclanche/connections-tui (for some definition of the word "I") -- you can jump by date and easily compare.

To be possibly even more pendantic: this quote does not imply otherwise.

The knife crime analogy is a bit off, as we already have age restrictions for buying knives in the UK.

I was pro-systemd at the time of the controversial discussions. I still think it's a net positive relative to what was there before. But personally speaking, it's only the core of the software (service management) that improved things for me. The other things (timers, journald) I either ignore or don't like, but perhaps they're useful for distributions.

I've been quite happy with -boot, -networkd, -resolved. -logind too, what a powerful upshift in routing input.

I forget what but timesync is missing a lot of nice to haves. But ditching grub for something much much much more manageable & a joy to use. Networkd and resolved have both had a lot of nice clear straightforward options, and I love how systemd unit files snap together for these networking concerns.

Journald has been ok for me, and I use it a lot, but not intensively. Having adequate performance is definitely a huge concern.

systemd-resolved is a godsend.

I run, at home and at work, vpns and having a good way to configure split-horizon dns is incredibly useful.

At a previous company we were able to ship a binary that would automatically configure a bunch of company settings on developers' linux laptops and got VPN configurations working with split-horizon dns very easily.

prior to this, doing split-horizon dns on linux basically meant running dnsmasq (!!!) on every linux laptop

I think if it was just service management most people wouldn't mind it nearly as much.

Yes, systemd's weirdly bundled system services largely suck. The ones that I'm sure about: journald is more annoying to use than syslog (it takes forever - like a minute on a top of the line CPU - to scan two months worth of logs) and resolvd has or used to have basic bugs that other systems don't have.

> The ones that I'm sure about: journald is more annoying to use than syslog (it takes forever - like a minute on a top of the line CPU - to scan two months worth of logs)

That sounds like an unequal comparison. For the same amount of log data and the exact same filter operation, journald should be strictly faster or equal to text logs. Are you sure this isn't because in your journald test you're going through a lot more logs? Because journald makes it easier/feasible to collect more logs.

No, journald shouldn't be strictly faster. It signs/encrypts/whatever the logs and stores them in some kind of structured format that needs to be converted to plaintext before processing it as such. That is not faster than just reading the plaintext. Grep and less search etc are very fast.

And no, I don't want to use the structured features. For error diagnosis, I want every occurrence of the search string in every field over a long time for comparison purposes.

> stores them in some kind of structured format

No, it stores them with binary metadata, rather than ASCII metadata. "Plaintext" needs to be parsed, which is expensive. You don't really think binary RPC formats like protobuf are slower than JSON because it's "structured format" compared to "plaintext" I hope. Or SQL databases are slower than CSV files.

> And no, I don't want to use the structured features.

I don't see why you'd prefer having to figure out different time formats to parse from different software logs compared to a standard time format.

I'm searching for "service name" and I don't care if it comes from "service" or mentions "service". That's unstructured.

The rest of your comment doesn't even apply. Search is not parsing and not structured data transfer (which is what binary RPC formats are for), and unless you have a fulltext index, there is no faster way to do it than the usual algorithms, which work at 100+ MB/s. With log files, the text is right there ready to be searched. With journald, it needs to be assembled first, and it's pretty slow in practice.

This legislation was created by the Conservative party, but wasn't opposed by any major political party in the UK.

> You're going to pay for that one later if you do the simple thing and add an "email" column

You'll only pay if the project survives long enough for that new requirement to actually surface, which often it won't.

I'm going to echo what everyone else is saying in this thread -- the inverse problem (YX) is by far the bigger issue with tech questions on the internet in general (mainly SO and IRC). It's common enough that it puts me off asking anything that's not entirely trivial. And yes, ChatGPT mitigates this to a large degree.

However there is definitely a place for pointing out XY problems in a work context, especially if you have to directly deal with the resulting code. You need a lot of shared context to have confidence that you've identified an actual XY problem.

Yep. Pre-generics, Java was considered a good teaching language because of its simplicity and the ability to hold the entire language in your head. I think it's much more difficult to make that argument now. The same for Python. Moreover, while Python 3's unicode/byte string separation was a crucial step, IMV other features from Python 3 haven't made a big impact on how useful the language is.