alxlaz

It's very hard to untangle it from the rest of its context (the prompt is built dynamically, from a lot of parts, some project-specific, some specific to my preferences, some built from interaction history), so I can't really share it. In any case, I don't think it's some specific prompt engineering sorcery I'm doing, it's not like I've spent any real time refining it or experimenting with various magical incantations. It's probably just some model features making it more amenable to the kind of instructions that are relevant in these cases (directness, questioning trade-offs, thoroughness etc.). My chatbot swears equally graphical in review prompts and news summarizing prompts so I'm pretty sure I'm not tickling the machine just right :)

I use their API for several models, both for personal and professional use. I think their approach (smaller, specialised models that are well-adapted for specific tasks) is a very good fit for how I work. And even the more general-purpose ones, like the chat model, just... refreshingly good in a lot of ways. My "ruthless review" prompt, which I use for, well, ruthless, guided reviews of early technical drafts, has good technical results for early reviews and holy crap is it ruthless and does it know how to swear. By the time Claude or ChatGPT are done being honest about how right I am to push back and gently circling back, Mistral's large model has sent me back to the drawing board twice.

Being in the EU does smooth a lot of things in terms of compliance, payment processing and whatnot, but I also like that their data retention and privacy policies are pretty clearly spelled out. I need to know something, there's a good chance it's explained outright somewhere and I don't need to read between the EULA lines and wonder what it means.

I do hit limits in terms of capabilities sometimes, and I'm sure other providers' services offer better results for some things. But the businesses ran on top of those more capable models feel too much like a scam at this point and I'd rather not depend on them for anything I actually need.

Yeah, the Arch wiki is the Gentoo wiki we lost. I was around for it and the Gentoo wiki was amazing, it was one of the best Linux resources all-around, it was tremendously useful even if you didn't use Gentoo.

> [German engineers and tech workers a]re not the kind to release half-baked products and patch issues later

What the article doesn't point out is that this is deeply ingrained not just among companies but among customers, too, and it's one of the many culture shocks I've seen my colleagues who move between US and EU markets experience.

If a European customer (adjusting for geographical variation, Europe is pretty big and diverse) runs into some weird issue and they call tech support, there's a very good chance that you've already lost them. It doesn't matter if tech support was super helpful, remedied things right away, and the customer support experience was top notch. The perception is that if they had tech support to un-break it, someone not only cut corners, but didn't even cut them very well, and now they wasted their time, too.

This isn't "just a cultural thing", it's ingrained because of how customers themselves do business, too (which makes it especially difficult to deal with in a B2B setting). The whole chain of commercial relations and norms is structured in such a way that depending on a "move fast and break things" platform is a very, very bad idea.

This is one of the most frequent things I had to explain in review meetings, and it went both ways:

- People who moved from US to EU markets didn't understand why customers had nothing but good words to say about customer support and then didn't renew contracts citing quality issues

- People who moved from EU to US markets going nuts over product release timelines getting aggressively slashed not so much because the feature sheet was too thin but because they thought there was no way to get those features tested enough

"Right" is a bit of a stretch. Manicured screenshots are a tiny subset of theming requirements. People went to great lengths to theme GTK because, for the longest time, Adwaita was truly atrocious, with poor contrast in inactive windows and retina-burning acid active colours.

KDE solved 99% of the theming requirements by just allowing color customisation and shipping with a default theme that doesn't suck too badly.

> some people I see DMs from and go "well there goes my morning hand-holding them through something they should already both know and have internalized".

Pre-emptively, I'm not saying anything below applies in your case :-).

A mismatch in the threshold of "they should already both know and have internalized" is where much of the friction in high-stress organisations comes from.

I see a lot of people expecting, as the parent post put it, "a clear set of steps that can be burned down [to get to a good result]", but entirely oblivious to the fact that the people they expect it from:

1. Don't have the organisational authority to organise it -- they can do "their part" but they can't tell people on whose work they depend what to do.

2. Don't have access to the same task-specific information as the person who expects it of them, and don't know who to ask because teams are heavily compartmentalised and/or hierarchical.

3. Don't have access to the same kind of organisational information as the person who expects it of them.

Much like responsibility, deflecting blame comes from above. In my experience, what the parent poster says is true: people who are bad at what they do and try to make it someone else's problem is probably the most common source of stress. But it is also my experience that the middle leadership layers of companies where this is a chronic problem is almost entirely populated by managers who try to make everything other people's problem, and whose teams end up having to deflect everything by proxy whether they want it or not.

I think this is part of the nuance that's lacking in the parent post. It's very hard for someone to work significantly above their organisation's level.

These aren't local credentials, these are credentials from various third-party websites that made their way into stealer logs. Garbled or not, using your personal email address for both legitimate purposes (e.g. Google Calendar, as the article points out) and honeypots isn't the best idea.

Ah, I thought you meant what sites list the stolen credentials. The exact overlap of websites across four separate stealer logs is enough to leak an email address pretty reliably. The only thing that's "telling" for is that they're not willing to dox this person.

They're linking to the original source of the news, which literally names "the sites".

Yeah, inputing "secure credentials" traceable directly to you with what you'd hope is a bogus password is a very bad idea, especially if you're doing highly secure work.

From the linked article:

> user names and passwords for logging in to various accounts belonging to Schutt have been published at least four times since 2023 in logs from stealer malware.

So this isn't from website dumps with plaintext passwords.

> My email appears in dumps on haveibeenpwnd too, because of database dumps. How is that evidence that there's a key logger on my system?

If your password is in the dumps, too, like this person's passwords, then yeah, you might want to look into it.

Oh, wow, have we come full circle -- from Apple breaking the law in a jurisdiction where they do business to, err, Cyprus, and Europe, and... Ivan the Terrible having somehow become a woman for half a sentence?

Touch some grass, mate, Apple isn't worth your energy. No company their size is, whether on this side of the Atlantic or the other.

Having accidentally argued against his own point with inadequate metaphors time and time again, OP returns to namecalling!

I see we're back to Coca Cola, McDonalds and Burger King. Oh, and Meta, somehow? This is about Apple, I think you're in the wrong thread.